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ABSTRACT 


A  common  problem  between  Military  applications  and  operators  is  the 
consistent  and  meaningful  exchange  of  data.  Currently,  several  models  and 
simulations  exist  for  the  purposes  of  training  and  analyzing  military  data.  Due  to 
the  absence  of  an  agreed-upon  standard  with  which  to  represent  unit  data,  much 
is  lost  during  interchange  and  applications  are  not  maximized.  This  thesis  is  a 
step  towards  a  solution. 

Extensible  Markup  Language  (XML)  technology  has  been  widely  accepted 
as  a  standard  for  representing  information  in  such  a  way  that  it  is  self- 
documenting,  self-validating  and  platform  independent.  By  using  the  Command 
and  Control  Information  Exchange  Data  Model  (C2IEDM),  formerly  known  as 
Generic  Hub,  and  XML  it  is  possible  to  develop  a  representation  of  unit  data  that 
is  extensible  and  broadly  useable  by  tactical  systems  and  human  operators  alike. 
This  thesis  approaches  the  problem  exploring  the  Model  Driven  Architecture 
(MDA)  and  the  Extensible  Modeling  Simulation  Framework  (XMSF)  as  possible 
overarching  architectural  concepts  for  a  global  solution. 

The  C2IEDM  is  used  as  the  core  data  interchange  model  for  this  research 
and  applies  XML  technologies,  schema  and  the  Extensible  Stylesheet  Language 
for  Transformations  (XSLT)  to  derive  a  formatted  data  representation  that  is 
acceptable  within  the  Flexible  Asymmetric  Simulation  Technologies  (FAST) 
Toolbox.  The  transformation  example  serves  as  template  for  other  simulation 
programs  to  follow  for  interchange  through  the  common  base  model. 

This  thesis  shows  that  by  using  a  common  data  representation  like 
C2IEDM  coupled  with  the  power  of  XML  and  XSLT,  unit  information  can  be 
transformed  and  interchanged  between  applications.  In  order  to  accomplish  this, 
an  extensive  analysis  is  done  on  recently  performed  and  ongoing  research  as 
well  as  the  development  of  an  exemplar  to  show  how  the  proposed  process  is 
completed.  The  result  of  this  work  is  a  transformation  of  unit  data  extracted  from 
an  example  C2IEDM  instance  file  that  is  compliant  with  the  schema  for  an  actual 
unit  order  of  battle  tool  used  for  modeling  and  simulation. 
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I.  INTRODUCTION 


A.  CRITICAL  PROBLEM  STATEMENT 

A  recurring  issue  in  simulation  as  well  as  command  and  control  system 
(CCS)  development  and  design  is  data  interchange.  Several  constructive 
simulations  exist  which  allow  military  commanders  to  train  their  staffs  and 
subordinate  commanders  for  war.  However,  there  is  not  a  fully  operational 
simulation  specifically  designed  to  train  commanders  and  staffs  for  stability  and 
support  operations  (SASO).  This  is  an  important  issue:  as  the  United  States 
moves  forward  in  its  global  war  on  terror  (GWOT),  it  finds  itself  ever  increasingly 
in  situations  where  forces  must  transition  from  combat  to  peace  support 
operations  (PSO).  In  order  to  adequately  train  for  this,  simulations  and  C2 
systems  must  communicate  in  order  to  support  unit  training.  The  data 
interchange  methods  employed  must  be  generic  yet  complete  enough  to  facilitate 
and  foster  their  training  use  and  transition  from  one  system  to  another. 
Additionally,  due  to  the  size  and  complexity  of  currently  available  simulations,  a 
host  of  contractor  support  is  generally  required  for  their  implementation  and  use. 
Generally  speaking,  most  simulations  have  been  independently  developed  by 
different  contractors  and  have  very  different  data  input,  output  and  structure 
requirements  that  foster  data  interchange  difficulties.  This  prevents  them  from 
being  used  in  conjunction  with  one  another  without  extensive  time,  effort  and 
specialized  interfaces,  such  as  the  High  Level  Architecture  (HLA). 

B.  OVERVIEW 

The  Extensible  Markup  Language  (XML)  has  become  the  standard  by 
which  businesses,  government  and  military  organizations  structure  and 
exchange  data.  The  Department  of  Defense  (DoD)  sees  the  potential  for  XML’s 
use  in  both  training  and  combat  information  exchange  systems  and  is  currently 
working  toward  converting  many  of  its  data  driven  applications  into  XML  format 
so  that  data  interchange  is  platform/application  independent  and  complete.  One 
initiative  under  development  is  the  Flexible  Asymmetric  Simulation  Technologies 
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(FAST)  Toolbox.  This  project  is  creating  a  toolbox  of  simulations,  databases, 
and  computational  models  designed  for  future  use  at  the  unit  level.  The 
Diplomatic  and  Military  Operations  in  a  Non-Warfighting  Domain  (DIAMOND) 
model  is  one  of  the  tools  included  in  the  FAST  Toolbox.  DIAMOND  is  a  high- 
level  modeling  tool  designed  for  use  in  PSO.  Developers  hope  that  once 
complete  and  validated,  DIAMOND  will  fill  the  requirement  for  a  SASO  planning 
and  training  tool  providing  a  simulation  model  suitable  to  draw  on  surrounding 
data,  tools  and  techniques  (DIAMOND,  2002). 

Additional  simulations,  models  and  a  Unit  Order  of  Battle  (UOB)  tool  are 
also  contained  within  the  FAST  Toolbox  providing  commanders  the  tools 
required  to  train  for  and  analyze  combat  scenarios  both  before  and  during 
conflict.  Different  military  contractors  have  developed  each  of  the  simulation, 
database  and  computational  tools  in  the  Toolbox.  As  part  of  the  testing  and 
validation  of  these  technologies,  the  Defense  Modeling  and  Simulation  Office 
(DMSO)  has  asked  one  of  its  participating  partners,  the  Naval  Postgraduate 
School  (NPS),  to  investigate  the  design  of  data  interchange  methods  between 
the  applications  within  the  FAST  Toolbox.  A  focus  area  of  concern  is  the 
interchange  of  data  between  command  and  control  systems  and  these  tools. 

This  thesis  is  another  step  in  ongoing  research  to  discover  a  solution  to  this 
problem  using  XML  technologies. 

This  thesis  provides  an  example  transformation  of  data  from  a  data  model 
used  in  command  and  control  systems  into  another  representation  scheme  that 
is  used  in  a  simulation/model  suite.  This  exemplar  shows  that  the  semantic 
interchange  of  tactical  data  is  possible  without  data  loss  or  inaccuracy. 

C.  MOTIVATION 

1.  Messages  from  the  Field 

Such  capabilities  are  mission  critical  and  widely  needed.  The  following 
observations  are  excerpts  from  email  messages  dealing  with  the  use  of 
simulations  for  both  training  and  wartime  operations.  Since  the  author  is  an 
Army  Simulation  Officer,  these  discussions  are  directly  relevant  and  have 

provided  a  strong  motivation  for  this  thesis  work. 
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Army  Simulation  Officers  enroute  to  and  from  Iraq  are  speaking  out  about 
the  need  for  simulation  and  modeling  tools  to  assist  them  in  becoming  more 
relevant  and  useful  to  their  commanders  in  mission  analysis,  wargaming  and 
course  of  action  development  and  analysis  phases  of  planning  during  wartime. 
This  topic  of  discussion  was  not  considered  an  issue  until  units  entered  war  with 
simulations  officers  assigned  to  them.  Throughout  the  shooting  war  and  now 
during  the  SASO  phase  of  operations  in  Iraq  the  question  has  become:  What  do 
we  do  now  that  we  are  not  training? 

I  would  hope  the  FA  57  (Simulations  Officer)  is  always  looking  for  a 
way  to  use  simulations  to  support  the  commander.  Could  a  FA  57 
incorporate  some  model  or  simulation  into  this  process  (our 
traditional  combat  operations  information  management  process)  to 
help  speed  up  our  decision  making  capability  or  provide  better 
battle  space  visualization?  The  answer  depends  upon  several 
variables:  Are  the  tools  available?  Is  the  staff  manned  and 
equipped  to  handle  such  capabilities?  Is  the  unit  even  receptive  to 
such  a  concept?  (personal  correspondence  from  COL  Wade  B. 

Becnel,  Chief,  Strategic  Experiential  Education  Group  (SEEG), 

Center  for  Strategic  Leadership  (CSL),  U.S.  Army  War  College,  3 
OCT  2003). 

The  answers  to  Colonel  Becnel’s  questions  are  no,  no  and  again 
(generally  speaking)  no.  Why  this  unfortunate  situation?  First,  the  Simulation 
Operations  functional  area  (FA57)  for  Army  officers,  which  is  a  part  of  the 
Information  Operations  career  field,  is  very  new.  Second,  as  computer 
technology  rapidly  increases,  the  Army  and  other  services  find  themselves 
playing  catch  up  when  trying  to  train  their  members  how  to  successfully 
implement  these  new  technologies.  To  be  fully  understood  many  of  these 
technologies  require  users  to  attend  advanced  civil  schooling  which  is  not  always 
possible.  Third,  the  simulation  and  modeling  tools  that  are  available  are 
generally  only  acceptable  for  use  at  the  very  highest  levels  for  planning  and 
analysis.  They  require  a  great  deal  of  time  and  support  to  operate  and  in  many 
cases  are  not  interoperable.  The  lower  the  level  of  command,  the  less  time  there 
is  for  database  and  scenario  initialization  that  might  enable  computers  to 
significantly  assist  what  experienced  commanders  and  staffs  do  routinely.  Thus 
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analog  methods  of  course  of  action  (COA)  development,  analysis  and  wargaming 
are  executed  the  way  they  are  taught  in  the  school  houses. 

The  warfighter  in  an  operation  doesn't  require  a  simulation  that  will 
tell  him  whether  one  COA  is  statistically  better  by  .006  than  another 
COA.  What  is  needed,  and  where  there  is  a  capability  gap,  is  a 
system  that  is  fast  enough  to  run  through  a  COA,  provide  some 
dirty  estimates  on  effects  and  deliver  a  credible  outcome.  The  trick 
is  that  this  outcome  would  be  achieved  through  wargaming  or 
rehearsals  by  the  warfighter  anyway  if  they  do  it  analog.  We  need 
to  leverage  tools  that  speed  up  this  process  (personal 
correspondence  from  Major  Mike  Panko,  Division  Simulations 
Officer,  1st  Armored  Division,  26  October  2003). 

Additionally,  the  Armed  Forces  of  the  United  States  as  well  as  Coalition 
forces  are  engaged  in  fast  paced,  unpredictable  urban  conflict  unlike  any  seen 
since  the  street  fighting  of  World  War  II.  Then  the  enemy  was  uniformed  and 
followed  prescribed  tactics,  techniques  and  procedures  that  in  some  cases  led  to 
his  defeat.  This  is  not  necessarily  the  case  now.  Current  operations  occur  so 
fast  that  there  is  no  time  to  fully  utilize  the  simulation  and  modeling  tools 
available.  The  FAST  project  is  a  step  towards  a  solution,  but  due  to  the  iterative 
nature  of  software  development  and  the  time  required  to  test  and  evaluate  useful 
tools  (Crain,  2002),  the  tools  are  not  available  when  and  where  they  are  needed 
most.  The  following  quote  emphasizes  this  point. 

As  far  as  FA57s  in  the  field  and  use  of  Sims  during  wartime  goes  I 
can  only  speak  for  1st  Armored  Division.  I  have  been  integrated  in 
as  a  Future  Ops  guy  and  one  of  the  Battle  Majors  that  deploys  with 
the  Assault  Command  Post  /  Division  Tactical  Assault  Command 
Post  (DTAC).  My  job  as  the  Division  Simulations  Officer  is  nominal 
only  right  now  and  there  is  nothing  in  the  immediate  future  that 
would  indicate  otherwise.  Given  that  the  Operation  Iraqi  Freedom 
(OIF)  has  become  a  SASO  environment  there  has  been  no  call  for 
Sims,  at  all,  to  think  through  courses  of  action  or  to  look  at 
contingencies.  There  is  no  time  to  pull  anything  together  and  frankly 
there  is  no  way  for  the  Division  to  run  any  kind  of  an  exercise  when 
the  day-to-day  business  is  all  consuming.  Only  Corps  and  higher 
have  the  resources  to  put  anything  together,  from  my  perspective 
(personal  correspondence  from  Major  Mike  Panko,  Division 
Simulations  Officer,  1st  Armored  Division,  20  SEP  2003). 
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Simulations  Officers  serve  a  dual  purpose  in  their  organizations.  They  are 
expected  to  be  experts  in  simulation  technologies  as  well  as  in  tactical  operations 
and  training. 

One  critical  near-term  'deployed'  role  FA57s  will  also  have  to  be 
prepared  for  and  is  only  hinted  upon  in  the  thread  is  in-theater 
training  (our  typical  garrison  role).  It's  been  a  long  time  since  the 
US  Army  has  had  to  refit  and/or  reconstitute  units  and  personnel  in 
a  combat  zone,  and  our  current  field  force  mix  of  analog,  digital, 
and  hybrid  analog-digital  units  will  make  this  task  even  more 
complicated.  With  the  units  currently  in  place,  casualties  will  create 
holes  in  organizations  where  people  will  have  to  be  replaced.  New 
arrivals  must  be  quickly  integrated  into  the  units'  ways  and  means 
of  doing  business.  With  the  host  of  non-standard  digital  equipment 
we  have  in  the  inventory  this  role  will  become  a  critical  function. 

When  it  comes  to  the  digital  equipment,  no  two  divisions  in  the 
entire  US  Army  have  the  same  match  of  equipment  unlike  the  more 
similar  CL  VII  (major  end  items)  (personal  correspondence  from 
Major  Brandon  Herl,  Operations  Officer,  Warrior  Training  Center, 

Korea,  20  September  2003). 

Lastly  message  traffic  from  LTC  Rene  Burgess  addressing  the  issue  of 
tools  available,  elicited  the  following: 

The  kicker  is  that  we  have  to  have  the  tools  -  low  overhead,  easy 
to  integrate,  easy  to  run  tools  that  do  a  "good  enough"  job  right 
now,  not  a  perfect  job  some  time  in  the  future.  There's  a  degree  of 
risk  in  this... both  from  the  agency  that  supports  the  right  now 
requirement,  and  in  the  57  in  the  field  using  a  tool  that  is  less  than 
perfect  (personal  correspondence  from  LTC  Rene  Burgess,  24 
October  2003). 

2.  DMSO  FAST  Project 

The  Defense  Modeling  and  Simulation  Office  (DMSO)  is  the  DoDs  lead 
agency  that  oversees  the  development,  management  and  acquisition  of  modeling 
and  simulation  (M&S)  tools  throughout  all  of  the  services.  At  the  present  time 
DMSO  is  working  on  a  project  that  promises  to  provide  better  simulation  and 
modeling  support  to  lower  levels  of  command.  DMSO’s  Military  Operations 
Other  Than  War  (MOOTW)  Flexible  Asymmetric  Simulation  Technologies  (FAST) 
Toolbox  project  is  designed  to  provide  ready  access  to  several  modeling  and 
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simulation  tools  that  will  eventually  assist  commanders  in  decision  support.  An 
issue  not  yet  resolved  is  the  level  of  command  this  toolbox  should  support. 

According  to  (Crain  and  others,  2004)  the  user  level  is  primarily  corps  and 
below  or  “is  intended  to  be  used  by  tactical  military  staff  members  at  the  division 
and  brigade  echelons  of  command  and  below.”  This  is  a  problem  because  of  the 
different  functionality  requirements  at  these  different  levels  of  command.  The 
Toolbox  currently  consists  of  the  following  pieces: 

•  Interim  Static  Stability  Model  (ISSM)  -  A  civil  stability  and  durable  peace 
model  that  is  applicable  at  the  strategic  and  operational  levels  of  war. 

•  Unit  Order  of  Battle  Data  Access  Tool  (UOB  DAT)  -  This  tool  allows  users 
to  tailor  forces  and  equipment  to  specific  missions  across  the  levels  of 
war. 

•  Diplomatic  and  Military  Operations  in  a  Non-warfiqhtinq  Domain 
(DIAMOND)  -  This  high-level  stochastic  simulation  is  focused  towards 
MOOTW  operations  and  advances  planning/analysis  at  the  operational 
and  tactical  levels. 

•  Joint  Conflict  and  Tactical  Simulation  (JCATS)  -  An  interactive  simulation 
for  conducting  training  and  mission  rehearsal  at  the  tactical  level. 

•  Canadian  Forces  Landmine  Database  (CFLD)  -  A  repository  of  landmine 
data  for  analyst  training  and  reference. 

D.  OBJECTIVES 

The  main  objective  of  this  thesis  is  to  provide  an  exemplar  to  show  that 
unit  data  represented  using  XML,  exchanged  using  the  C2IEDM  and  transformed 
using  the  XSLT,  provides  a  recipe  for  successful  data  transfer.  A  subsequent 
objective  is  to  compare  two  versions  of  the  C2IEDM  model,  one  which  uses  a 
database  to  hold  its  data  and  another  that  strictly  uses  XML  to  describe  the  data. 
Figure  1  illustrates  the  research  intent.  Using  the  C2IEDM  document  oriented 
schema  developed  by  Capt.  James  Neushul  (Neushul,  2003)  and  a  C2IEDM 
source  file  generated  from  that  schema  by  XMLSpy,  a  stylesheet  written  using 
XSLT  extracts  and  formats  necessary  unit  information  from  the  source  file  that  is 
required  by  applications  within  the  FAST  Toolbox.  A  result  document  is  created 

6 


and  is  validated  against  the  (JOB  schema  governing  all  data  files  used  within  the 
FAST  Toolbox  to  ensure  compliance.  Future  work  suggests  the  development  of 
additional  transformations  that  can  convert  C2IEDM  source  files  into  and  out  of 
other  formats  to  be  used  with  other  simulation  and  modeling  packages  within  the 
DoD. 


E.  ORGANIZATION  OF  THESIS 

Chapter  I  provides  an  introduction  that  encompasses  a  working  problem 
statement,  an  overview  of  the  problems  involved  with  data  interchange,  the 
motivation  for  this  thesis  work,  the  objectives  of  the  thesis  and  finally  the 
organization  of  the  thesis  document. 

Chapter  II  discusses  more  background  and  related  work  that  are 
referenced  and  expounded  upon  in  other  thesis  chapters.  Topics  include  a 
discussion  of  XML  technologies  including  the  Extensible  Modeling  and 
Simulation  Framework  (XMSF),  an  overview  of  the  MOOTW  FAST  Toolbox,  a 
discussion  of  data  interoperability  and  interchange  as  well  as  scenario 
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interchange,  the  Command  and  Control  Information  Exchange  Data  Model 
(C2IEDM),  the  Battle  Management  Language  (BML),  Extensible  Battle 
Management  Language  (XBML)  and  lastly  the  TOPTIVA  application. 

Chapter  III  discusses  the  Model  Driven  Architecture  (MDA)  which  is  an 
enterprise-scale  software  development  methodology.  Produced  by  the  Object 
Management  Group  (OMG),  the  MDA  predicates  itself  on  using  models  and 
modeling  software  to  autogenerate  computer  code  for  processes  that  require 
complete  documentation  and  that  are  easily  updatable.  The  MDA  is  examined 
for  its  potential  use  in  assisting  to  solve  data  interchange  difficulties. 

Chapter  IV  reviews  the  Unit  Order  of  Battle  (UOB)  Toolset  and  its 
component  parts:  Databases,  Data  Access  Tool  (DAT)  and  Data  Interchange 
Format  (DIF).  UOB  is  an  authoritative  source  of  unit  order  of  battle  information 
due  to  its  completeness  and  relative  ease  of  use. 

Chapter  V  discusses  the  development  of  an  exemplar  transformation  from 
a  C2IEDM  source  document  showing  how  data  extracted  from  the  C2IEDM 
model  can  be  transformed  using  XSLT  into  a  format  used  within  the  FAST 
technologies  arena.  This  chapter  introduces  development  of  XML  documents 
and  schema  and  touches  on  the  mental  processes  involved  in  the  design  and  the 
development  of  the  XSLT  used  for  the  exemplar  transformation. 

Chapter  VI  contains  conclusions  based  on  the  work  accomplished, 
successes  achieved  and  short  falls  experienced.  Recommendations  for  future 
extensions  of  this  work  are  discussed. 
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II.  BACKGROUND  AND  RELATED  WORK 


A.  INTRODUCTION 

This  chapter  provides  needed  background  by  synopsizing  related  work 
that  is  referenced  and  utilized  in  this  thesis.  Topics  include  a  discussion  of  XML 
technologies  including  the  Extensible  Modeling  and  Simulation  Framework 
(XMSF),  an  overview  of  the  Flexible  Asymmetric  Simulation  Technologies 
(FAST)  Toolbox,  a  discussion  of  data  interoperability  and  interchange  as  well  as 
scenario  interchange,  a  discussion  of  the  Army  Tactical  Command  and  Control 
Information  System  (ATCCIS),  an  introduction  to  the  Multilateral  Interoperability 
Programme  (MIP)  and  its  relationship  to  the  Command  and  Control  Information 
Exchange  Data  Model  (C2IEDM).  The  C2IEDM  is  introduced  and  both  strengths 
and  weaknesses  are  briefly  discussed.  The  Battle  Management  Language 
(BML)  and  Extensible  Battle  Management  Language  (XBML)  are  reviewed  and 
the  TOPTIVA  application  is  introduced. 

B.  EXTENSIBLE  MODELING  AND  SIMULATION  FRAMEWORK  (XMSF) 

The  Extensible  Modeling  and  Simulation  Framework  (XMSF),  is  defined 
as  a  composable  set  of  standards,  profiles  and  recommended  practices  for  web- 
based  modeling  &  simulation  (M&S).  Its  basic  precept  is  that  XML-based  markup 
languages,  Internet  technologies  and  Web  Services  will  enable  a  new  generation 
of  distributed  M&S  applications  to  emerge,  develop  and  interoperate.  XMSF 
integrates  several  high-level  requirements  derived  from  years  of  experience  with 
M&S  frameworks  and  the  challenges  of  their  effective  deployment  across  diverse 
networks  and  systems  (Brutzman  and  others,  2002).  XMSF  is  not  an  application 
or  architecture,  but  a  set  of  standards  for  technical  solutions  as  well  as  processes 
for  building  distributed  solutions  establishing  a  technical  framework  and  an 
engineering  process  for  M&S  applications  utilizing  web  services  and  technologies 
(Tolk  and  Pullen,  2003). 

The  XMSF  working  group  consists  of  several  partners  working  on  three 
action  areas.  Those  areas  are  Web/XML,  Internet/Networking,  and  Modeling  and 
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Simulation  (M&S).  The  motivation  behind  the  XMSF  project  is  the  application  of 
open  standards  and  open  source  solutions  to  increase  the  efficiency  and 
applicability  of  distributed  simulation  systems. 

XMSF  is  a  work  in  progress  and  as  such  several  key  factors  have  been 
identified.  Foremost  is  that  XMSF  must  not  be  constrained  by  proprietary 
technology  that  would  stifle  the  open  development  of  new  technologies.  It  must 
be  human  and  agent  friendly  and  must  support  composable,  reusable  model 
components.  It  must  be  scalable  enabling  simulations  to  interact  directly  over 
distributed  networks.  In  the  context  of  the  Model  Driven  Architecture,  XMSF  can 
be  viewed  as  a  web-based,  “platform  specific”  solution,  with  the  objective  to 
identify  the  necessary  base  functionality  for  distributed  M&S  applications  (Tolk 
and  Pullen,  2003). 

XMSF  uses  an  extensible  framework  of  XML-based  languages  that 
provide  a  bridge  for  legacy  and  future  M&S  requirements  and  systems.  Three 
goals  or  challenges  for  XMSF  which  are  of  key  importance  to  military  simulation 
professionals  are: 

1.  To  provide  open,  affordable,  extensible  modeling  and  simulation 
capabilities  for  tactical  scenarios  of  direct  use  to  participants 
engaged  in  conflict  and  peace  operations. 

2.  To  improve  the  ease  of  use  for  developers  and  users,  fueling  rapid 
growth  of  interoperable  simulations. 

3.  To  provide  support  for  all  types  and  domains  of  M&S:  constructive, 
analytical,  live,  virtual,  playback-driven,  agent-based,  human-in-the- 
loop,  heterogeneously  distributed,  logistical,  and  others  (Brutzman 
and  others,  2002). 

An  issue  of  interest  when  discussing  XMSF  is  the  topic  of  ontologies.  An 
ontology  is  an  “explicit  formal  specification  of  how  to  represent  the  objects, 
concepts  and  other  entities  that  are  assumed  to  exist  in  some  area  of  interest 
and  the  relationships  that  hold  among  them”  (Dictionary,  2004).  Webster  defines 
ontology  as  a  basis  of  meaning  of  something.  Ontologies  require  precise 
vocabularies  that  are  acceptable  to  all  parties.  XML  Schema  and  Namespaces 
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are  two  methods  used  within  XML  to  establish  vocabularies  which  then  can  be 
used  as  the  basis  for  ontologies.  Much  of  the  work  done  on  the  XMSF  project 
has  yielded  the  fact  that  the  capabilities  for  such  a  framework  exist  and  are 
robust  enough  for  web-based  simulation.  The  main  issues  now  revolve  around 
how  to  integrate  the  many  technologies  into  the  one  coherent  framework. 
Ontology  research  leading  toward  creation  of  a  Semantic  Web  where  software 
can  access  and  reason  about  information  on  the  Web  is  a  key  direction  for 
military  M&S  work  (Blais,  2004a). 

One  item  of  concern  within  the  XMSF  concept  is  the  issue  of  the  timing  of 
technological  evolution  and  availability.  The  M&S  focus  group  of  the  XMSF 
project  has  directed  its  energies  into  the  two  areas  of  refining  technical  issues 
and  defining  use  cases  which  test  the  reach  of  the  XMSF  concept.  The  timelines 
set  forth  for  these  two  areas  define  near  term  as  1-2  years,  mid  term  as  3-5  years 
and  long  term  as  greater  than  5  years.  Considering  todays  operational 
environment,  solutions  to  XMSF  problems/issues  need  to  be  geared  towards 
“good  enough”  for  near  term  implementation  and  fielding  with  continuing  work 
towards  perfecting  solutions  in  the  later  time  frames.  Warfighters  need  workable 
solutions  quickly  rather  than  notionally  perfect  solutions  5  years  from  now. 

In  summary,  XMSF  can  be  described  as  an  evolutionary  strategy  toward 
advanced  distributed  simulation  using  open  standards  -  in  particular  standards 
related  to  the  web  -  complementary  to  the  high  level  architecture  (HLA)  to  reach 
the  next  level  of  this  domain  of  distributed  computing  (Tolk  and  Pullen,  2003). 

C.  FLEXIBLE  ASYMMETRIC  SIMULATION  TECHNOLOGIES  (FAST) 

TOOLBOX 

The  Flexible  Asymmetric  Simulation  Technologies  (FAST)  Toolbox  is 

sponsored  by  the  Defense  Modeling  and  Simulation  Office  (DMSO).  The  original 

concept  of  a  FAST  Toolbox  came  from  the  Military  Operations  Other  Than  War 

(MOOTW)  Toolbox  concept  of  operations  (CONOPS)  (Crain,  2002).  The 

purpose  of  the  CONOPS  is  to  provide  a  long-range  vision  for  the  development  of 

modeling  and  simulation  (M&S)  capabilities  that  support  the  needs  of  the 

Warfighter  for  the  planning  and  conduct  of  MOOTW.  Additionally,  the 

development  of  the  MOOTW  “M&S  in  a  Rucksack”  is  intended  to  complement, 
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rather  than  compete  with,  current  and  planned  U.S.  Department  of  Defense 
(DoD)  M&S  MOOTW  capabilities  and  developmental  programs.  Where  possible 
and  as  appropriate,  the  MOOTW  Toolbox  is  intended  to  incorporate  and  leverage 
other  U.S  governmental  agencies,  U.S  non-governmental  agencies,  foreign 
governments,  international  non-governmental  agencies  and  private 
organizational  MOOTW  M&S  advances  and  efforts  (Crain,  2002). 

The  current  FAST  Toolbox  project  incorporates  the  Joint  Conflict  And 
Tactical  Simulation  (JCATS),  the  Diplomatic  and  Military  Operations  in  a  Non- 
Warfighting  Domain  (DIAMOND),  the  Unit  Order  of  Battle  Data  Access  Tool 
(UOB  DAT),  the  Interim  Static  Stability  Model  (ISSM)  and  the  Canadian  Forces 
Land  Mine  Database  (CFLD).  This  toolbox  is  meant  to  be  rapidly  deployable  on 
a  single  laptop  computer  and  used  at  the  warfighting  level  for  military  planning 
and  aiding  course  of  action  development  and  analysis.  Recent  work  published 
for  the  Spring  Simulation  Interoperability  Workshop  extends  the  possibilities  of 
the  FAST  Toolbox  viewing  it  as  an  exemplar  of  the  XMSF  project  based  on  a 
profile  approach  taking  into  account  the  Interoperability  Profile,  Implementation 
Profile  and  Security  Profile  of  the  project  (Blais,  2004b). 

D.  DATA  INTEROPERABILITY  AND  DATA  INTERCHANGE 

Recent  research  conducted  by  Capt  James  Neushul  USMC,  focused  on 
the  abilities  of  open  source,  non-proprietary  driven  software  to  afford  military 
leaders  the  flexibility  to  not  only  visualize  the  battlespace  using  3D  visual 
graphics  but  also  to  communicate  across  the  boundaries  of  platform 
dependencies  and  control  their  data  using  XML  technologies  (Neushul,  2003). 

An  excerpt  from  a  report  coming  from  Iraq  emphasizes  his  point. 

A  Lessons  Learned  report  from  Operation  Iraqi  Freedom  (OIF) 
describes  an  inability  to  effectively  communicate  battlespace 
geometry  for  planning  due  to  software  incompatibilities,  and  cited  a 
lack  of  adequate  National  Imagery  support  during  preparation  or 
combat  phases.  These  observations  describe  problems  with 
access  to  dynamic  data  as  it  is  generated  on  the  battlefield,  and 
static  data  that  has  been  collected  and  archived  so  that 
commanders  can  put  battlespace  information  in  a  visual  geographic 
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context.  There  is  a  fundamental  disconnect  between  the 
warfighter  and  the  data  that  supports  battlespace  visualization 
(Neushul,  2003,  6). 

A  common  theme  running  through  this  work  is  the  use  of  open-source 
software,  non-proprietary  data  standards  and  service-oriented  contracts  so  that 
military  leadership  can  gain  and  maintain  control  over  their  information 
processing  needs.  Capt.  Neushul’s  research  emphasizes  multiple  times  that: 

Software  must  be  required  to  be  as  adaptable  and  flexible  as  the 
individuals  that  use  it.  Demands  must  be  made  that  force 
extensibility  and  Network-Centricity.  Current  practices  of  software 
licensing  at  the  expense  of  data  control  must  be  rejected,  and 
solutions  that  enable  common  visualization,  and  that  incorporate 
information  exchange  data  models  must  be  adapted  at  all  levels 
(Neushul,  2003,  17). 

Captain  Neushul  also  discusses  an  extensibility  paradigm  that  sounds 
much  like  one  of  the  driving  concepts  behind  the  MDA,  which  is  platform 
independence.  The  ability  to  develop  applications  that  may  be  used  regardless 
of  the  operating  system  or  hardware  platform  on  which  they  will  be  applied  is  a 
key  to  many  ideas  dealing  with  extensible  web-based  technology  usage.  Data 
control  via  XML  Schema  is  addressed  here  and  detailed  examples  are  presented 
providing  evidence  of  the  validity  of  the  arguments  made. 

Battlefield  visualization  is  also  discussed  and  an  example  of  how  this  can 
be  accomplished  using  X3D  (Web3D,  2004),  GeoVRML  (GeoVrml,  2004)  and 
Scalable  Vector  Graphics  (SVG)  (W3C,  2004),  is  provided,  demonstrating  the 
power  of  XSLT  and  the  X3D  language  to  transform  binary  elevation  data  into  a 
graphically  viewable  format  in  a  web  browser.  Because  of  his  work,  3D  views  of 
standard  Digital  Terrain  Elevation  Data  (DTED)  (DTED,  2004),  data  are  now 
available  to  authorized  users  with  access  to  web  browsers,  and  warfighters  in  all 
theatres  have  the  ability  to  use  this  tool  to  examine  terrain  that  they  may  need  to 
control. 
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E.  SCENARIO  INTERCHANGE 

Many  Navy  efforts  use  the  Naval  Simulation  System  (NSS)  (Naval 
Simulation  System,  2004)  as  a  force-on-force  modeling  and  analysis  tool.  The 
original  design  intent  of  the  NSS  allowed  NSS  systems  to  communicate  with  one 
another  while  they  were  connected  via  a  High  Level  Architecture  (HLA)  Run  Time 
Infrastructure  (RTI).  This  communication  is  done  through  the  use  of  vendor- 
specific  RTI  application  programming  interfaces  (API).  Recent  thesis  work 
completed  at  the  Naval  Postgraduate  School  used  the  NSS  to  examine  scenario 
interchange.  The  research  demonstrated  the  ability  to  use  XML  to  represent 
NSS  scenario  data  so  that  NSS  users  could  interchange  scenario  data  amongst 
themselves  and  possibly  other  applications.  The  use  of  XSLT  to  transform 
scenario  data  into  a  textual  format  was  also  explored  to  enhance  NSS 
capabilities  (Hout,  2003).  Central  to  this  research  is  the  desire  to  exchange  data 
between  NSS  users  and  other  applications  using  the  host  of  XML  technologies. 

F.  ARMY  TACTICAL  COMMAND  AND  CONTROL  INFORMATION 

SYSTEM  (ATCCIS) 

“ATCCIS  was  founded  in  1980  to  see  if  interoperability  could  be  obtained 
at  reduced  cost  and  developed  according  to  technical  standards  agreed  upon  by 
multiple  Nations  and  prescribed  by  NATO”  (MIP,  2004).  The  objective  of  the 
Army  Tactical  Command  and  Control  Information  System  (ATCCIS)  (ATCCIS, 
2004)  was  and  continues  to  be  to  investigate  whether  interoperability  through  the 
development  of  a  set  of  minimum  standards  for  information  interchange  can  be 
achieved  at  a  reduced  cost  and  developed  according  to  technical  standards 
prescribed  by  the  North  Atlantic  Treaty  Organization  (NATO)  and  its  participating 
nations.  The  program’s  goal  was  to  identify  a  minimum  set  of  specifications  to  be 
included  within  command  and  control  (C2)  systems,  allowing  interoperability 
between  those  systems.  The  ATCCIS  program  was  not  a  formal  NATO  program, 
instead  it  was  a  voluntary  and  independent  activity  sponsored  by  the  Supreme 
Headquarters  Allied  Powers  Europe  (SHAPE). 

The  ATCCIS  specification  is  a  managed  interface  between  C2  information 
systems.  It  encompasses  two  parts:  a  data  model  and  a  replication  mechanism 
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called  the  ATCCIS  Replication  Mechanism  (ARM).  The  ARMs  function  is  to  keep 
information  up  to  date  in  cooperating  systems  whenever  a  C2  application 
changes  the  state  of  information  it  holds.  The  meaning  and  context  of  the 
information  do  not  change  and  require  no  additional  processing  (NATO,  2002). 
When  incorporated  into  a  system,  ATCCIS  enables  interoperability  of  information 
between  other  systems  that  also  incorporate  the  same  specification.  The 
information  exchange  requirements,  both  horizontal  and  vertical,  upon  which 
ATCCIS  is  founded,  encompass  the  spectrum  of  Joint  and  Combined  Land 
Operations.  ATCCIS  has  only  one  interface  and  is  not  concerned  with  the 
implementation  or  the  display  of  any  country  C2  systems.  As  such,  each 
country’s  command  and  control  systems  may  be  wholly  different  from  each  other 
and  do  not  have  to  conform  to  any  hardware  or  software  standard.  The  ATCCIS 
program  was  merged  with  the  Multilateral  Interoperability  Program  (MIP)  in  the 
early  part  of  2002. 

G.  MULTILATERAL  INTEROPERABILITY  PROGRAM  (MIP) 

The  Multilateral  Interoperability  Program  (MIP)  (MIP,  2004),  was 
established  in  1998  as  a  merger  of  two  other  programs:  the  Battlefield 
Interoperability  Program  (BIP)  and  the  Ouadrilateral  Interoperability  Program 
(OIP).  “The  aim  of  the  Multilateral  Interoperability  Programme  (MIP)  is  to  achieve 
international  interoperability  of  Command  and  Control  Information  Systems 
(C2IS)  at  all  levels  from  corps  to  battalion,  or  lowest  appropriate  level,  in  order  to 
support  multinational  (including  NATO),  combined  and  joint  operations  and  the 
advancement  of  digitization  in  the  international  arena.”  (MIP,  2003,  5)  In  2002 
the  Army  Tactical  Command  and  Control  System  merged  with  MIP.  ATCCIS  and 
MIP’s  parallel  goals  and  development  led  to  this  natural  merging.  MIP  is  the 
custodian  for  the  C2IEDM  which  is  an  extensible  data  model  that  provides  a 
method  for  exchanging  command  and  control  data. 

H.  COMMAND  AND  CONTROL  INFORMATION  EXCHANGE  DATA 

MODEL  (C2IEDM) 

The  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM) 
is  a  product  of  the  analysis  of  a  wide  spectrum  of  allied  information  exchange 
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requirements  by  1 6  nations.  It  is  one  of  two  parts  that  made  up  the  ATCCIS.  It 
models  the  information  that  allied  land  component  commanders  need  to 
exchange  (both  vertically  and  horizontally).  It  serves  as  the  common  interface 
specification  for  the  exchange  of  essential  battlespace  information  (NATO,  2002). 
The  model  was  designed  to  achieve  two  separate  but  related  goals,  one  of  which 
is  focused  on  in  this  thesis.  That  goal  is  to  describe  objects  in  the  battlespace 
(objects  for  the  purposes  of  this  work  are  units).  This  description  includes  the 
characteristics  of  the  objects,  their  status,  their  locations,  their  interrelationships, 
capabilities,  addresses,  and  other  properties.  The  second  goal  that  will  not  be 
investigated  here  is  the  goal  of  describing  activities  of  those  objects  in  the 
battlespace.  The  ATCCIS  ARM  mentioned  above  complements  the  C2IEDM. 

The  command  and  control  information  exchange  data  model’s  primary 
purpose  is  the  generic  representation  of  command  and  control  information.  It  is  a 
data  model.  “The  C2IEDM  is  a  container  document  that  captures  the  information 
and  data  modeling  artifacts.  This  document  is  also  used  as  a  standard  to  support 
national  implementations  of  C2  applications  and  supports  national  data 
management  activities  outside  of  the  MIP.”  (MIP,  2004c).  Due  to  the  extensive 
development  of  the  model  and  complete  documentation,  many  government 
organizations  are  currently  moving  towards  using  C2IEDM  as  their  predominant 
data  model.  It  comes  as  no  surprise  that  the  Department  of  Defense  is  one  of 
those  organizations.  Figure  2  portrays  the  concept  behind  the  MIP/C2IEDM 
project. 
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Effective  C2  For  International  Operations 


Commander 


Common  understand^ 


Figure  2.  Concept  of  Information  Transfer  envisioned  by  the  software 
developers  at  the  Institute  for  Defense  Analysis  (IDA)  (From  Simaitis,  2004). 


The  C2IEDM  models  command  and  control  information  that  combined 
arms  and  joint  combined  commanders  want  and  need  to  exchange  through  the 
use  of  an  entity-relationship  type  model  (MIP,  2003c).  “C2IEDM  is  intended  to 
represent  the  core  of  the  data  identified  for  exchange  across  multiple  functional 
areas  and  multiple  views  of  the  requirements.  Toward  that  end,  it  lays  down  a 
common  approach  to  describing  the  information  to  be  exchanged  in  a  command 
and  control  (C2)  environment”  (MIP,  2003c,  12).  Objects  in  C2IEDM  are 
classified  as  either  types  or  items.  Figure  3  shows  the  OBJECT-ITEM  and 
OBJECT-TYPE  structures.  Object-types  and  items  are  the  building  blocks  of  the 
model  and  are  related  through  the  OBJECT-ITEM-TYPE  structure.  Each 
contains  entities  that  provide  further  detail  to  information  being  transmitted. 

Figure  4  provides  a  high  level  view  of  the  C2IEDM  model  that  includes  some  of 
the  associations  and  entity  relationships  seen  in  the  model.  Figures  5  and  6  show 
the  expanded  OBJECT-TYPE  and  OBJECT-ITEM  constructs  from  the  model. 
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Figure  3.  Core  Kernel  of  C2IEDM  containing  OBJECT-TYPE,  OBJECT-ITEM 
and  OBJECT-ITEM-TYPE  constructs.  (From  Johnson,  2004). 


1 .  Strengths  of  the  Model 

The  C2IEDM  has  a  broad  range  of  applicability  which  is  further  enhanced 
through  the  ability  of  adding  national  extensions.  The  models  central  concepts 
have  been  stable  for  12  years.  The  documentation  that  speaks  to  these 
concepts  is  complete  and  detailed.  The  model  has  a  multinational  pedigree. 
Over  25  countries  are  currently  represented  within  the  MIP  and  are  actively 
engaged  in  the  development  of  the  model  for  their  country’s  military  use.  The 
semantic  content  of  the  model  can  be  enriched  to  suit  the  needs  of  any 
community  of  interest  (COI).  Lastly  the  model  is  relatively  easy  to  extend  in 
response  to  operational  data  requirements.  Each  participating  nation  within  the 
MIP  at  some  point  has  or  may  need  to  create  extensions  to  support  their 
warfighting  doctrine  and  operational  procedures.  An  example  of  a  U.S.  led 
extension  being  proposed  to  NATO  is  found  in  the  area  of  Chemical,  Biological, 
Radiological,  and  Nuclear  (CBRN)  messaging  and  operations.  The  US  CBRN 
community  of  interest  (COI)  evaluated  the  C2IEDM  and  found  it  deficient  for 
representing  NBC  data  required  for  requisite  NBC  C2  systems  (Johnson,  2004). 
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Figure  4.  High  level  view  of  the  C2IEDM  model  showing  the  many  to  many 
relationships  between  the  different  entities  of  the  model  (From  Johnson,  2004). 


To  address  the  models  shortcomings  for  their  community,  they  developed 
the  CBRN  Data  Model  as  part  of  a  larger  CBRN  Data  Initiative. 

The  mission  of  the  data  initiative  is  to  promote  the  interoperability 
and  reuse  of  CBRN  Data  across  the  Joint  Warning  and  Reporting 
Network  (JWARN),  the  Joint  Effects  Model  (JEM),  the  Joint 
Operational  Effects  Federation  (JOEF)  programs  and  other  CBRN 
programs.  The  primary  goal  is  to  eliminate  interoperability  failures 
by  mapping  current  and  legacy  CBRN  data  to  a  common  reference 
schema.  The  use  of  a  data  schema  promotes  data  reuse  and 
standardization.  To  ensure  commonality  with  joint  and  coalition 
C4ISR  systems  the  data  schema  begins  with  a  subset  of  the  NATO 
Command  and  Control  Information  Exchange  Data  Model 
(C2IEDM),  adds  in  those  data  elements  needed  to  fully  describe 
CBRN  information,  and  relates  that  information  to  the  existing  C4 

19 


data  elements  resident  in  the  current  version  of  the  C2IEDM.  This 
work  will  result  in  a  common  data  schema  that  can  be  used  by  all 
CBRN  applications  that  need  to  interface  with  joint  and  coalition  C4 
systems  including  simulation  systems  (O’Keefe,  2003,  1-2). 

The  CBRN  Data  Model  data  exchange  standard  offers  a  technologically 
sound  structure  for  Multi-Service  interoperability  development  across  NBC 
specific  domains.  The  extended  structure  may  also  allow  non-NATO  Coalition 
Interoperability  within  the  current  NATO  security  posture. 
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Figure  5.  OBJECT-TYPE  relational  tree  found  in  the  C2IEDM  (From  Johnson, 

2004). 
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Figure  6.  OBJECT-ITEM  relational  tree  found  in  the  C2IEDM  (From  Johnson, 

2004). 

Thus  extensions  to  C2IEDM  have  been  successfully  demonstrated.  Figure  7 
shows  a  portion  of  the  CBRN  Data  Model  with  showing  two  specific  extended 
elements  CBRN  DETECTION  and  CBRN  EVENT.  Figure  8  shows  the  expanded 
CBRN  EVENT  namespace  used  within  the  CBRN  Data  Model.  Additional 
elements  of  the  CBRN  Data  Model  can  be  seen  in  Figure  8.  Figure  9  shows  the 
level  of  detail  that  is  possible  in  extensions  to  the  C2IEDM.  As  with  any  model, 
extensions  must  follow  the  syntactic  rules  and  conventions  of  that  model. 

Figures  8  and  9  display  several  of  the  syntactic  conventions  used  to  describe 
CBRN  data  in  the  CBRN  Data  Model.  Whether  the  CBRN  Data  Model  will  be 
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eventually  accepted  as  a  formal  extension  of  the  C2IEDM  remains  the  object  of 
continued  work. 


Figure  7.  Extended  C2IEDM  showing  the  CRBN  event  (From  Johnson,  2004). 


Figure  8.  CRBN-EVENT  construct  of  Extended  C2IEDM  showing  additional 

detail  (From  Johnson,  2004). 
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CB  RN -DETECTION 

cbrn-detection-id. action-event-id:  NUMBER(15)  (FK) 

cbrn-detection-location-id. location-id :  NUMBER(15)  (FK) 

sensor-id. materiel-id:  NUMBER(15)  (FK) 
cbrn-detection-sam pie-type-code:  CHAR(6) 
cbrn-detect ion-type-code:  CHAR (6) 

agent-type-id. consumable-materiel-type-id:  NUMBER(15)  (FK) 
deposition-contamination-quantity:  NUMBER(12,3) 
inhalation-contam ination -quantity:  NUMBER(12,3) 
cbrn-detected-dos e-quantity:  NUMBER(12,3) 
cbrn-detected-dos e-rate:  NUMBER(13,4) 
deposition-concentration-quantity:  NUMBER(12,3) 
inhalation-concentration-quantity:  NUMBER(12,3) 
cbrn-detected-concentration-tim e-rate:  NUMBER(13,4) 
cbrn-d os  e-rate-trend-code:  CHAR(6) 
cbrn-actual-decay-rate:  NUMBER(7,2) 
cbrn-relative-decay-rate-code:  CHAR(6) 
cbrn-detection-datetime:  DATE 
cbrn-gen eric -alarm -result-code:  CHAR(6) 
cbrn-potential-h arm -result-code:  CHAR(6) 
cbrn-confirmation-test-code:  CHAR(6) 
cbrn-results -assurance-level-code:  CHAR(6) 
cbrn-detected-agent-purity -fraction:  NUMBER(6,5) 


C  B  R  N -SCEN  A  R 10 -D  ETAIL 
cbrn-scenario-id:  NUMBER(15)  (FK) 
cbrn-scenario-index:  NUMBER(15) 

cbrn-e vent-id:  NUMBER(15)  (FK) 

•  action-event-id:  NUM  B  ER(1 5)  (FK) 
cbrn-detection-id:  NUMBER(15)  (FK) 

• - -  — 

I 
I 
I 

CBRN-EVENT  • 

i 

cbrn-event-id. action-event-id:  NUMBER(15)  (FK) 

cbrn-e  vent-category-code:  CHAR(6) 

cbrn-e  vent-subcategory -code:  CHAR(6) 

cbrn-e  vent-alarm -result-indicator-code:  CHAR(6) 

cbrn-event-confirmation-test-indicator-code:  CHAR(6) 

cbrn-event-start-datetime:  DATE 

cbrn-event-end-datetime:  DATE 

cbrn-e  vent-occurrence-qualifier:  CHAR(6) 

cbrn-event-type-code:  CHAR(6) 

cbrn-e  vent-delivery-mechanism -code:  CHAR(6) 

burst-location-type-code:  CHAR(6) 

cbrn-e  vent-initial-size-diameter:  NUM  BE  R(  12,3) 

cbrn-event-confirmed-location-id. location-id:  NUMBER(15)  (FK 


Figure  9.  Expansion  of  several  nodes  of  the  CRBN  C2IEDM  extension  (From 

Johnson,  2004). 


Further  information  and  Instructions  for  requesting  extensions  to  the 
C2IEDM  can  be  found  in  (MIP,  2003a). 

2.  Weaknesses  of  the  Model 

For  all  of  its  strengths,  the  C2IEDM  also  has  limitations.  According  to  the 
Institute  for  Defense  Analysis  (IDA)  the  model  is  relatively  simple  and 
understandable  (Simaitis,  2003).  Depending  on  the  background  of  the  reader 
and  the  representation  used  this  may  not  be  the  case.  The  current  C2IEDM 
Version  6.1  schema  provided  by  IDA  is  much  easier  to  understand  than  the 
Battlespace  Information  Exchange  Schema  (BIXS)  created  by  Capt.  James 
Neushul  representing  the  same  data  exchange  model.  One  of  the  reasons  for 
this  is  IDAs  use  of  a  database  to  hold  all  of  the  data  elements  in  the  model.  This 
technique  makes  the  IDA  version’s  structure  much  flatter  and  easier  to  traverse. 
This  comes  at  a  cost  however.  The  use  of  a  database  creates  problems  for 
those  developers  who  want  the  model  absolutely  exposed  and  extensible;  i.e.,  in 
a  human-readable,  human-modifiable  and  document-centric  structure.  The 
document-centric  version  of  the  schema  produced  by  Neushul  uses  only  native 
XML  to  represent  the  data  held  within  the  model.  Since  the  model  contains  many 
relationships,  data  in  the  BIXS  must  be  replicated  completely  in  many  different 
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locations  throughout  the  model.  While  the  BIXS  version  of  the  C2IEDM  is  human 
readable,  it  is  not  necessarily  understandable.  Multiple  representations  of  the 
data  throughout  the  schema  potentially  confuse  users  if  they  are  not  familiar  and 
comfortable  with  the  C2IEDM  itself.  Future  work  suggests  methods  to  help 
reduce  some  of  the  BIXS  complexity. 

I.  BATTLE  MANAGEMENT  LANGUAGE  (BML)  AND  XBML 

The  Battle  Management  Language  (BML)  (MSIAC,  2004)  is  defined  as  an 
“unambiguous  language  used  to  command  and  control  forces  and  equipment 
conducting  military  operations  and  to  provide  for  situational  awareness  and  a 
shared,  common  operational  picture”  (Tolk  and  Pullen,  2003,  10).  BML  is 
intended  for  use  in  exchanging  command  and  control  information  between 
individuals  using  C2  systems,  simulations  and  future  robotic  forces.  Four 
principles  have  guided  the  development  of  BML.  The  first  is  that  BML  must  not 
be  ambiguous.  Second,  it  must  not  constrain  the  military  commander’s  intent 
within  the  limits  of  the  military  operational  domain.  Third,  it  must  use  and  be 
compatible  with  existing  C3I  systems.  Finally,  it  must  allow  all  systems  and 
participants  to  communicate  information  about  themselves,  their  mission,  and 
their  environment  in  order  to  create  situational  awareness  and  a  shared,  common 
operational  picture.  BML  also  supports  data  consistency  by  checking  the  data 
used  in  simulation  initialization,  decision  support  and  the  recommended  courses 
of  action  that  are  derived  from  iterative  simulation  runs  using  the  actual 
operational  context. 

Currently  the  most  widely  used  format  for  military  communications  is  free 
text.  The  reason  for  this  is  that  the  underlying  vocabularies  are  defined  in  the 
doctrinal  manuals.  However  a  difficulty  with  using  free  text  is  that  to  be 
understood  the  context  in  which  the  text  is  used  must  be  clear.  This  is  not 
always  the  case.  Current  messaging  context,  whether  in  the  form  of  operations 
orders,  fragmentary  orders  or  warning  orders,  depends  on  the  backgrounds  of 
the  sender  and  receiver,  the  operational  context,  and  the  branch  of  service  of 
both  the  sender  and  receiver.  In  terms  of  information  processing,  machines  do 
not  do  well  with  ambiguity.  For  this  reason  an  XML  Repository  was  added  to  the 
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BML  development  process  to  capture  the  harmonized  results  of  mixing  doctrinal 
manuals  (semantic  content)  and  C3I  data  models  to  check  the  consistency  of 
messages,  orders,  courses  of  action,  scenarios,  and  other  context  sensitive 
military  information. 

XBML  is  an  XML  version  of  BML  that  can  be  utilized  as  a  web  service  via 
XML/SOAP  and  C2IEDM.  The  following  is  a  list  of  supporting  technologies  for 
the  project: 

.  XMSF 

.  C2IEDM 

•  Structured  Representation  of  Doctrine 

•  Doctrinal  Definitions  and  Task  Lists:  Joint  Level  Definitions  and  Task 
Lists;  e.g.  Joint  Pub  1-02  Dictionary  of  Terms  and  Universal  Joint  Task 
List  (UJTL) 

•  Service  Definitions  and  Dictionaries;  e.g.,  FM  101-5-1  Operational  Terms 
and  Graphics 

•  Service  Task  Lists;  e.g.  FM  7-  15,  The  Army  Universal  Task  List  (AUTL) 
(Hieb,  2003). 

The  XBML  project  is  currently  focusing  on  taking  an  existing  Army  BML 
testbed  and  using  Simple  Object  Access  Protocol  (SOAP)  /X ML  interfaces  to 
develop  a  demonstration  of  XBML’s  utility.  The  goal  is  to  develop  a  testbed  for 
“plugging  in”  C4I  and  simulation  systems  (see  Figure  10)  (Hieb,  2003).  Ongoing 
work  includes  harmonizing  BML  semantic  constructs  with  the  C2IEDM  data 
model. 
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Figure  10.  Pictorial  representation  of  the  XBML  Testbed  (From  Heib,  2003). 


LEGEND: 

BML  Battle  Management  Language 

GUI  Graphical  User  Interface 

OTB  OneSAF  Testbed 

SOAP  Simple  Object  Access  Protocol 

CAPES  Combined  Arms  Planning  and  Execution  System 
J.  TOPTIVA 

The  Theater  Anti-Submarine  Warfare  Combat  System  (TASWCS) 
Operational  Task  (OPTASK)  Interactive  Viewing  Application  (TOPTIVA)  is  a 
command  and  control  application  that  exposes  the  functional  areas  of  the  MIP 
C2IEDM  project  (Brutzman,  2004).  The  TOPTIVA  application  was  developed  at 
the  Naval  Undersea  Warfare  Center  (NUWC)  Newport  Rl  and  uses  the  C2IEDM 

as  the  data  exchange  format  for  tactical  operational  information  via  the 
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Operational  Context  exchange  Service  (OCXS).  This  service  is  an  XML 
messaging  service  that  has  also  been  developed  by  NUWC.  TOPTIVA  contains 
a  graphical  user  interface  (GUI)  that  allows  users  to  visualize  orders  that  have 
been  transmitted  via  the  OCXS  messaging  service.  Figure  1 1  shows  a  snapshot 
of  TOPTIVAs  OpenMap™  presentation  layer. 


Figure  1 1 .  OpenMap™  screen  shot  from  TOPTIVA  which  uses  the  C2IEDM 

data  model. 

In  its  current  state  TOPTIVA  only  incorporates  a  small  fraction  of  the  total 
C2IEDM.  Work  continues  to  fully  develop  this  technology  so  that  it  may  be 
incorporated  into  more  submarine  combat  control  system  (CCS)  simulation 
exercises  as  well  as  other  virtual  battle  experiments  for  the  U.S.  Navy. 

K.  SUMMARY 

This  chapter  has  reviewed  several  pieces  of  research  geared  towards 

increasing  the  military’s  ability  to  exchange  data  within  the  C2  and  simulation 
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communities  of  interest.  It  has  reviewed  the  current  issues  dealing  with  the  lack 
of  integration  and  extensibility  of  current  systems  and  solutions  to  these 
problems  using  XML  technologies  and  extensible  frameworks.  XML  is  the 
prevailing  technology  in  most  applications  and  areas  where  the  qualities  of 
extensibility,  openness  and  integration  are  necessary.  Most  of  the  examples 
discussed  in  this  chapter  focus  heavily  on  the  necessary  ability  to  interchange 
information  between  applications  and  amongst  new  and  existing  systems.  This 
focus  is  prevalent  throughout  the  DoD  as  it  has  become  readily  apparent  that  the 
current  stovepiped  methodology  of  system  development  with  a  later  desire  for 
integration  and  interoperability  is  no  longer  acceptable.  All  of  the  efforts 
discussed  in  this  chapter  are  attempting  to  harness  existing  technologies  for  the 
enhancement  of  the  nation’s  warfighting  and  defense  capabilities. 


28 


III.  MODEL  DRIVEN  ARCHITECTURE  (MDA) 


A.  INTRODUCTION 

This  chapter  discusses  the  Model  Driven  Architecture  (MDA).  MDA  is  a 
software  development  methodology  that  predicates  itself  on  using  models  and 
modeling  software  to  autogenerate  computer  code  for  processes  that  require 
complete  documentation  and  that  are  easily  updatable.  The  MDA  is  examined 
for  its  potential  use  in  assisting  to  solve  data  interchange  difficulties. 

B.  MDA  DEFINITION 

The  Object  Management  Group’s  (OMG)  Model  Driven  Architecture 
(MDA)  provides  an  approach  for  designing  and  building  component  based 
systems  that  remain  decoupled  from  the  languages,  platforms  and  middleware 
environments  that  are  eventually  used  in  the  implementation  of  those  systems.  A 
key  characteristic  of  the  MDA  process  is  the  ability  of  an  organization  to  be  able 
to  model  their  systems  once  and  then  transition  them  over  time  as  standards  and 
infrastructure  technologies  become  more  mature  (Parr  and  Keith-Magee,  2003). 

The  essence  of  MDA  is  that  the  criterion  of  executable  software 
architecture  should  be  driven  by  the  formulation  of  models  rather 
than  by  manually  writing  source  code.  Source  code  is  generated 
from  the  models  by  a  compilation  step  much  as  machine  code  is 
generated  from  source  code.  The  MDA  initiative  aims  to  move 
software  development  to  a  higher  level  of  abstraction  (Arlow  and 
Neustadt,  2003,  50) 

The  MDA  concept  has  evolved  from  the  need  to  build  solutions  for 
widespread  software-development  computing  problems  in  business.  It  is  a 
simple  concept  to  explain  yet  much  more  difficult  to  employ,  since  the 
technologies  necessary  to  realize  MDA  concept  have  not  been  fully  developed 
and  implemented.  Prior  to  code  implementation,  a  development  cycle  is  followed 
to  make  the  concept  of  an  application  a  reality.  This  development  cycle 
sometimes  follows  a  waterfall  model,  sometimes  not,  but  generally  is  an  iterative 
process  that  includes  feedback  from  the  client  for  whom  the  application  is  being 
developed.  Traditionally,  during  the  design  phase,  high-level  models  are  created 
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on  paper,  white  boards  etc.  to  describe  the  concepts  and  functionalities  required 
and  necessary  for  the  application. 

A  common  complaint  in  software  design  and  development  is  the  lack  of 
detailed  documentation  accompanying  developed  software.  Many  programmers 
believe  that  their  only  job  is  to  write  the  code  implementing  a  solution  to  a 
particular  problem  they  have  been  given.  They  believe  that  it  is  someone  else’s 
responsibility  to  compile  the  documentation  necessary  for  the  purposes  of 
understanding  the  development  process,  the  potential  problems  and  the 
requirements  for  upgrading  or  maintaining  the  application  software.  A  second 
complaint  during  this  design  phase  is  that  a  lot  of  work  has  been  done  to  develop 
a  model  of  the  application  but  no  progress  is  made  on  writing  the  code  to 
implement  the  solution.  Often  developers  want  to  skip  this  part  of  the  process 
because  they  feel  that  they  are  wasting  their  time.  They  know  that  the  models 
and  documentation  developed  in  this  stage  are  useful  but  that  they  will  be  out  of 
date  and  relatively  useless  once  the  project  is  complete. 

MDA  is  an  attempt  to  correct  this  trend.  Its  goals  are  to  use  and  develop  if 

necessary  the  graphical  modeling  tools  needed  in  the  design  process  and  to 

make  them  more  robust  so  that  they  actually  do  more  than  just  graphically 

represent  the  application  under  development.  During  the  implementation  of  the 

MDA  process  different  models  come  into  existence.  In  keeping  with  current 

trends  of  extensibility,  MDA  is  driven  to  use  concepts  and  tools  that  will  allow 

extensibility.  To  do  this,  the  MDA  is  designed  to  first  develop  a  platform- 

independent  model  (PIM)  that  abstractly  reflects  the  application.  The  modeling 

tool  used  to  create  this  model  includes  functionality  to  create  the  computer 

software  to  fully  implement  this  model.  An  important  point  is  that  the  Object 

Management  Group  (OMG)  considers  source  code  to  be  a  valid  model  since  it  is 

a  formal  specification  that  has  a  distinct  semantic  meaning  and  models 

executable  machine  code  that  is  developed  through  the  use  of  an  interpreter  and 

compiler  (Arlow  and  Neustadt,  2003).  Once  PIM  development  is  complete,  a 

transformation  process  is  used  on  this  model  which  generates  subsequent 

platform-specific  models  (PSMs).  These  PSMs  are  tailored  to  the  platform  on 
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which  they  will  operate.  Again  during  a  transformation  process,  the  modeling  tool 
generates  the  computer  software  necessary  for  the  model  to  run  on  that 
particular  platform.  This  platform-specific  model  then  undergoes  a 
transformation  that  generates  application  software. 

In  addition  to  the  models  and  software  to  run  the  application,  software  that 
adds  functionality  between  like  and  unlike  systems  is  created  during  the 
transformational  processes.  This  software  acts  as  and  is  called  a  bridge.  Since 
the  information  is  present  for  each  of  the  models  to  know  what  is  required  of 
them,  it  is  possible  to  generate  specific  bridges  to  connect  the  different  platforms. 
C.  MDA  STRUCTURE 

1.  Platform-Independent  Model  (PIM) 

This  is  the  high  level  model  created  during  the  design  process  which  takes 
into  account  all  of  the  functionality  of  the  application  under  development.  This 
model  is  based  on  a  high  level  of  abstraction  and  is  focused  towards  the  best 
solution  to  the  problem  at  hand.  This  model  has  no  ties  to  operating  systems  or 
other  proprietary  software  or  system.  PIMs  are  the  most  abstract  of  the 
architecture  models  and  are  the  most  valuable. 

2.  Platform-Specific  Models  (PSM) 

These  models  directly  result  from  the  platform  independent  model.  “A 
PSM  is  tailored  to  specify  your  system  in  terms  of  the  implementation  constructs 
that  are  available  in  one  specific  implementation  technology”  (Kleppe,  2003). 
They  contain  both  business  and  platform  information,  are  created  by  mapping  the 
PIM  to  a  particular  platform  stack,  are  detailed  models  using  Unified  Modeling 
Language  (UML),  and  are  the  basis  of  source  code  and  associated  artifacts 
(Arlow  and  Neustadt,  2003).  PSMs  are  less  abstract  than  PIMs  and  are  used  to 
generate  source  code,  which  in  turn  is  the  least  abstract  feature  of  the  MDA. 

3.  Source  Code 

Source  code  is  generated  in  one  of  two  ways.  It  is  manually  generated  by 
the  application  programmer  or  it  is  generated  through  the  modeling  tool,  an 

example  of  which  is  executable  UML.  Source  code  is  the  least  abstract  model  in 
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the  MDA  process  but  it  is  considered  by  the  OMG  to  be  a  model  since  it 
represents  machine  language. 


Figure  12.  Steps  in  MDA  development  Process  (From  Kleppe  and  others, 

2003). 


D.  USING  MDA  FOR  DATA  MODELING 

The  original  thesis  intent  is  depicted  in  Figure  13.  The  goal  there  was  to 
use  the  (JOB  version  7.7  schema  as  the  target  structure,  populated  with  data 
extracted  from  the  Battlefield  Information  Exchange  schema  (BIXS).  The  BIXS 
acts  as  the  PIM  and  the  (JOB  acts  as  the  first  in  a  series  of  PSMs.  Once  the  unit 
information  was  formatted  correctly  using  the  UOB  structure  it  could  be  further 
transformed,  using  XSLT,  into  other  PSMs  usable  within  the  FAST  Toolbox  such 
as  JCATS  and  DIAMOND.  This  concept  was  originally  supported  by  such 
statements  as 

Models  suitable  for  use  in  the  MDA  have  to  be  written  in  a  well- 
defined  language  (Kleppe,  2003)  which  XML  is  and  that  in  reality  it 
is  difficult  to  draw  the  line  between  platform  independent  and 
platform  specific.  Is  a  model  written  in  UML  specific  for  the  Java 
platform  because  one  of  the  class  diagrams  defines  one  or  more 
interfaces?  Is  a  model  that  describes  the  interactions  of 
components  specific  for  a  certain  platform  only  because  some  of 
the  components  are  ‘legacy’  components,  which  may  be  written  in, 
let’s  say,  COBOL?  It  is  hard  to  tell  (Kleppe,  2003,  22). 

Using  XML  and  XSLT  to  conduct  the  required  modeling  appears  to  work 
in  the  abstract,  but  there  are  concerns  that  this  idea  may  not  necessarily  conform 
to  the  intent  of  the  MDA. 
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Schema  Modeling 

Currently  Exists  Using  MDA 


indicate  “validates” 

Figure  13.  Original  thesis  model  utilizing  MDA  concepts. 

Since  the  OMG  stated  that  code  is  itself  a  model,  all  of  the  data  modeling 
necessary  for  this  work  could  be  represented  using  XML.  XML  is  a  meta  markup 
language  which  can  be  applied  to  design  other  languages  used  to  provide 
structure  to  text  documents  which  makes  them  well  defined.  However,  XML  is 
also  considered  a  type  of  implementation,  so  its  use  as  part  of  the  PIM  may 
violate  the  MDA  intent,  although  the  modeling  language  is  not  the  real  issue, 
expressing  the  abstract  model  is.  It  can  be  argued  that  C2IEDM  is  a  specific 
implementation  as  well.  A  PSM  represents  a  specific  application  instead  of  a 
specific  language  used  to  develop  an  application.  From  this  perspective,  JCATS 
and  DIAMOND  are  PSMs. 

The  use  of  XSLT  for  transforming  data  models  parallels  the  MDA 
transformation  process.  However  as  discussed  previously,  the  differentiation  of 
what  constitutes  a  PSM  or  PIM  depends  on  the  developer’s  point  of  view.  For 
data  modeling,  there  is  a  one-to-one  mapping  of  the  concepts  from  MDA  to  XML 
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based  technologies.  However,  UML  is  the  prevailing  modeling  language 
specifically  extensible  UML,  mentioned  in  the  MDA  literature  that  is  necessary  to 
make  MDA  fully  functional.  Other  technologies  were  introduced  such  as  the 
Extensible  Metadata  Interchange  (XMI)  and  Enterprise  Java  Beans  (EJB)  but  it 
was  apparent  that  since  the  OMG  is  the  developer  and  custodian  to  the  UML,  it  is 
the  tool  recommended  for  successful  implementation  of  the  MDA. 

E.  NEXT  STEPS 

While  using  MDA  may  be  the  method  some  businesses  will  attempt  to  use 
for  the  development  of  their  software  applications  in  the  future  it  appears  that 
MDA  is  not  yet  the  best  method  in  the  context  of  this  thesis.  Several  limitations 
of  the  MDA  of  note  follow.  First  MDA  is  software  centric  even  though  the  OMG 
desires  it  not  to  be  and  it  is  focused  on  an  application’s  architecture.  Secondly, 
the  tools  to  fully  implement  the  MDA  are  promising  but  are  still  emerging  and 
generally  speaking  are  too  advanced  for  the  average  user.  Third,  reworking 
legacy  systems  so  that  they  fall  into  the  architecture  is  not  only  difficult  but 
prohibitively  expensive. 

Generally,  the  intent  of  the  MDA  is  sound  but  the  necessity  to  be  an  expert 
using  only  certain  tools  to  implement  the  architecture  is  not.  It  is  not  clear  how 
technologies  like  XML  and  XSLT  fit  within  the  MDA.  Further  maturity  in  MDA 
software  tools  and  greater  availability  of  well-adopted  examples  may  eventually 
change  this  situation.  Rearchitecting  large  numbers  of  diverse  legacy  software 
systems  is  not  a  practical  approach.  Instead,  this  thesis  looks  at  correlating 
tactical  data  models,  so  that  XML-based  documents  and  message  interchange 
might  achieve  broad  interoperability  in  daily  practice. 
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IV.  UNIT  ORDER  OF  BATTLE  (UOB)  TOOLSET 


A.  INTRODUCTION 

This  chapter  introduces  the  Unit  Order  of  Battle  (UOB)  Toolset  and  its 
component  parts,  the  data  sources  found  within  UOB,  the  Data  Access  Tool 
(DAT)used  to  extract  information  from  the  databases  and  the  Data  Interchange 
Format  (DIF)  used.  The  UOB  is  an  authoritative  source  for  unit  order  of  battle 
information  due  to  its  completeness  and  relative  ease  of  use.  Additional 
information  about  the  UOB  and  instructions  for  downloading  the  tool  may  be 
found  are  discussed  in  (UOB,  2004). 

Before  proceeding,  two  questions  need  to  be  answered.  First,  what 
comprises  a  complete  unit  description?  This  question  must  take  into 
consideration  both  DoD  and  NATO/coalition  forces  if  it  is  to  be  complete. 
Normally,  Order  of  Battle  (OOB)  consists  of  identification,  strength,  command 
structure,  and  disposition  of  the  personnel,  units,  and  equipment  of  any  military 
force  (Hout,  2003).  Secondly,  where  might  the  information  be  located?  Several 
data  sources  currently  exist  that  contain  unit  information.  The  answers  to  both  of 
these  questions  appear  to  be  located  within  the  UOB  Toolset  located  within  the 
FAST  Toolbox. 

DMSO’s  Data  Engineering  program  sponsors  the  UOB  Toolset.  The 
project  was  put  together  to  address  the  problem  of  too  many  unit  order  of  battle 
sources  with  overlapping  and  sometimes  inconsistent  data.  The  UOB  Toolset  is 
the  most  acceptable  source  of  unit  order  of  battle  comprised  to  date. 

B.  UOB  TOOLSET 

The  Unit  Order  of  Battle  (UOB)  Toolset  consists  of  three  main 
components:  a  library  of  UOB  data  sources,  a  data  access  tool  (DAT),  and  a  data 
interchange  format  (DIF).  Figure  14  depicts  the  UOB  DATs  major  components 
and  pictorially  represents  their  interactions. 
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UOB  DAT’s  Three  Major  Components 

users 


Unit  OB  Authoritative  Sources 


UOB  DIF 


Force  Structure  8  Analysis 
Operational  Plan  Development 
Analysis  8  Training 
Test  &  Evaluation 
Professional 
Military  Education 

In  Knowledge  Acquisition 

T-0ltrcto°wVs,eEW  & 

■  select 

■  extract 

■  edit/save 


Access  Tool  to  Task  Organize  & 
Produce  TOs  in  standard  Format 


1.  Authoritative  UOB  Data  Sources 


2.  UOB  Data  Access  Tool  (DAT) 


3.  UOB  Data  Interchange  Format  (DIF) 


Figure  14.  The  UOB  Toolset  Components  (From  Cipparone  and  Hopkins, 

2003) 


1.  UOB  Data  Sources 

As  was  mentioned  earlier,  UOB  data  is  available  from  a  variety  of  sources. 
These  include  both  U.S.  and  non-U. S.  forces  at  UNCLASSIFIED  and  SECRET 
classification  levels.  DMSO's  Authoritative  Data  Sources  project  has  identified 
several  sources  of  UOB  data  (Hopkins,  1999).  Currently,  the  UOB  Toolset 
provides  access  to  a  significant  number  of  these  data  sources.  Organizations 
owning  units  maintain  the  UOB  source  data  and  provide  them  in  their  native 
formats  to  the  maximum  extent  possible.  To  address  the  need  for  authoritative 
classified  UOB  data,  the  Toolset  provides  access  to  the  following  classified 
resources. 
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•  Conventional  Forces  Database  (CFDB)  -  The  CFDB  was  created  by  US 
Central  Command  (CENTCOM)  under  the  sponsorship  of  the  Joint  Staff 
(JS)  J8’s  Modern  Aids  to  Planning  Program  (MAPP)  and  contains  current 
data  about  US  Army,  Navy,  Air  Force,  and  Marine  units,  personnel,  and 
equipment  from  many  sources.  The  CFDB  is  updated  twice  a  year  and  is 
distributed  by  the  Office  of  Defense  (OD)  Program,  Analysis,  &  Evaluation 
(PA&E).  The  database  is  classified  as  SECRET. 

•  Global  Status  of  Resources  and  Training  System  (GSORTS)  and  the 
Global  Command  and  Control  System  (GCCS)  -  two  authoritative 
operational  data  sources  for  US  Army,  Navy,  Air  Force,  and  Marine  units, 
personnel,  and  equipment.  These  two  sources  are  classified  SECRET. 

•  Modernized  Integrated  Database  (MIDB)  -  MIDB,  created  by  the  Defense 
Intelligence  Agency  (DIA),  contains  general  military  intelligence  data  on 
many  foreign  facilities,  units,  personnel,  equipment  and  targets.  The  MIDB 
database  is  classified  SECRET. 

•  ForceGen  -  created  by  the  National  Ground  Intelligence  Center  (NGIC). 
ForceGen  is  an  Authoritative  Data  Source  (ADS)  of  information  and 
contains  eighteen  countries  UOB  data  with  projections  ahead  for  twenty 
years.  This  database  is  classified  SECRET. 

•  Conventional  Forces  Europe  (CFE)  -  The  CFE  contains  U.S.  Units 
located  in  Europe  and  forces  of  other  countries  in  Europe  that  are 
members  of  the  arms  control  agreements.  This  database  is  unclassified 
but  only  available  on  the  SIPRnet  and  DMSO’s  MOOTW  tool  kit. 


To  address  the  need  for  unclassified  data,  the  Toolset  also  provides  access  to: 

•  Unclassified  ForceGEN  -  Contains  non-U. S.  forces,  maintained  by  the 
NGIC.  The  database  contains  both  a  heavy  and  light  force  structure. 
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•  Army  MTOE  -This  database  contains  all  Army  Units  with  their  authorized 
and  required  personnel  and  equipment  data.  There  are  two  versions  of 
this  source:  one  that  provides  unit  information  down  to  the  Company  level 
and  one  that  provides  unit  information  down  to  the  lowest  Army 
organizational  level,  usually  the  team  level.  This  database  is  maintained 
by  U.S.  Army  Force  Management  System  Agency  (USAFMSA). 

•  Generic  U.S.  units  -  This  is  an  extract  from  the  Type  Unit  Cargo 
Characteristics  (TUCHA)  Joint  Operations,  Planning  and  Execution 
System  (JOPES)  reference  file. 

•  Non-Governmental  Organizations  (NGOs)  -  This  consists  of  selective 
approximations  of  Non-Governmental  Organizations  (NGO),  Private 
Volunteer  Organizations  (PVO),  and  International  Organizations  (10)  that 
have  been  constructed  and  added  to  the  database  for  use  with 
applications  concerned  with  MOOTW. 

•  Characteristics  and  Performance  (C&P)  data  -  A  link  has  also  been 
created  between  significant  unit  equipment  and  the  SPIRIT  and  JANES 
C&P  databases. 

In  the  future,  DMSO  plans  to  expand  the  UOB  data  available  via  the 
Toolset  by  including  future  year  projected  data  for  U.S.  Army  units  from  Total 
Army  Equipment  Distribution  Program  (TAEDP)  and  the  DIA  National  Futures 
Database  (NFDB)  (Cipparone  and  Hopkins,  2003). 

2.  UOB  Data  Access  Tool  (DAT) 

The  UOB  DAT  provides  access  to  the  UOB  data  sources  identified  above 

and  the  ability  to  manipulate  UOB  data  to  serve  specific  application 

requirements.  The  DAT  is  a  tool  using  both  server  and  client  relationships  in  a 

virtual  data  warehouse  architecture.  Only  the  client  Data  Access  Tool  and  any 

UOB  data  the  user  chooses  to  save  locally  are  resident  at  the  user's  site.  The 

authoritative  UOB  data  server  is  resident  at  the  data  producer's  location  and  is 

accessible  by  the  client  DAT  across  the  public  Internet  (for  unclassified  data)  or 

the  SIPRNET  (for  classified  data).  This  architecture  ensures  that  UOB  DAT  users 
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are  accessing  the  most  currently  available  data  from  the  authoritative  sources.  It 
also  alleviates  the  need  to  replicate  and  maintain  (JOB  data  storage  at  each 
user's  site.  The  producers  of  the  authoritative  data  are  responsible  for  storing 
and  maintaining  the  data.  The  data  access  tool  features  a  graphical  user 
interface  depicted  in  Figure  15,  which  allows  users  to  retrieve  and  browse  unit 
order  of  battle  data  and  associated  information  and  select  individual  units  easily 


and  quickly  across  distributed  networks. 


UOBDAT  Client 


||@g|il|[l]|^|4[|4r|4r|a|l|^|ll|^| 


JeJx 


File  View  Window  Help 


Figure  15.  The  (JOB  DAT  Main  Browser/Editor  Screen. 


3.  UOB  Data  Interchange  Format  (DIF) 

The  UOB  DIF  is  the  last,  critical  component  of  the  UOB  Toolset 
established  by  DMSO.  By  utilizing  this  single  format,  M&S  developers  have 
access  to  data  from  a  variety  of  UOB  data  sources.  This  interchange  format 
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eliminates  the  need  to  develop  an  understanding  of  each  (JOB  data  source's 
format  and  the  need  to  write  interfaces  unique  to  each  data  source.  The  UOB 
DIF  is  based  on  data  element  standards  submitted  to  the  DoD  Data 
Standardization  Program  and  encompasses  the  key  information  elements 
common  to  the  authoritative  data  sources  enumerated  above.  Logically,  the 
UOB  DIF  is  comprised  of  five  interrelated  sets  of  information: 

1 .  Identification  of  units  and  their  organizational  hierarchy. 

2.  Aircraft  associated  with  units. 

3.  Personnel  associated  with  units. 

4.  Equipment  associated  with  units. 

5.  Aircraft  /  equipment  characteristics  and  performance  data. 

The  UOB  DIF  has  implemented  four  of  the  above  items  as  either  ASCII  comma 
delimited  or  fixed  width  files.  A  portion  of  the  UOB  DIF  data  model  is  shown  in 
Figure  16. 
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Figure  16.  Pictorial  representation  of  part  of  the  UOB  Data  Model  (From 

Cipparone  and  Hopkins,  2003). 
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The  logical  and  well-structured  format  of  the  (JOB  Toolset  allows  users  of 
military  unit  data  to  tailor  the  data  to  fit  the  needs  of  their  models  and  simulations. 
The  (JOB  schema  that  describes  the  structure  of  an  extracted  (JOB  file  is  the 
guiding  structure  target  used  during  the  document  development  in  this  work. 

C.  SUMMARY 

The  (JOB  consists  of  three  main  parts:  a  Data  Access  Tool  (DAT),  a  Data 
Interchange  Format  (DIF),  and  several  databases.  The  databases  comprise  a 
complete  and  thorough  compilation  of  classified,  unclassified,  U.S.  and  Foreign 
military  unit  information  that  is  accessible  using  the  DAT.  The  DAT  allows  users 
to  manipulate  unit  information  though  the  use  of  an  intuitive  graphical  user 
interface.  The  DIF,  based  on  standards  developed  for  the  DoD  Standardization 
Program,  holds  the  key  information  elements  common  to  the  authoritative  data 
sources  held  within  the  UOB. 
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V.  UNIT  DATA  TRANSFORMATION 


A.  INTRODUCTION 

Chapter  V  addresses  the  transformation  of  unit  data  extracted  from  the 
BIXS  C2IEDM  using  XSLT.  This  chapter  provides  an  exemplar  showing  the 
power  of  XSLT  to  transform  the  data  extracted  from  the  BIXS  C2IEDM  into  the 
format  governed  by  the  UOB  version  7.7  schema.  Appendix  A  contains  the  (JOB 
schema.  Appendix  B  contains  the  extracted  UOB  unit  file  which  provides  an 
example  of  what  the  result  document  may  look  like  after  the  transformational 
process.  Based  on  the  conventions  used  in  a  schema,  Appendix  C  is  the  XSLT 
stylesheet  written  to  conduct  the  transformation.  Appendix  D  is  the  result 
document  from  the  XSLT  transformation.  Appendix  E  is  the  schema  developed 
by  the  author  prior  to  his  ability  to  extract  files  from  the  UOB  and  Appendix  F  is 
the  result  document  developed  by  the  Author  that  validates  against  Appendix  D. 

It  should  be  noted  here  that  several  documents  may  be  compliant  with  the  same 
schema  but  may  not  look  exactly  alike.  The  reader  will  notice  subtle  differences 
between  the  extracted  UOB  file  and  the  XSLT  result  document.  Both  documents 
are  UOB  schema  compliant. 

B.  XML  SCHEMA  DEFINED,  DISCUSSED  AND  COMPARED 

What  is  an  XML  schema?  “An  XML  schema  is  any  type  of  model 
document  that  defines  the  structure  of  something”  (Hunter  and  others,  2003, 

217).  Perhaps  a  better  way  to  look  at  it  in  the  context  of  this  effort  is  that  a 
schema  defines  an  XML  tagset  according  to  the  W3C  XML  Schema 
recommendation.  This  work  focuses  on  an  XML  document  describing  a  military 
unit.  XML  Schemas  are  themselves  XML  documents,  so  they  use  the  XML 
syntax  and  support  XML  Namespaces.  Namespaces  allow  the  combining  of 
elements  from  different  XML  Schemas.  They  provide  a  method  for  development 
of  ontologies  by  allowing  several  elements  with  the  same  name  but  from  different 
XML  languages  to  be  used  in  a  single  document.  Elements  are  differentiated 
from  one  another  based  upon  their  assigned  namespace. 
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XML  Schemas  contain  data  types  that  can  be  either  simple  or  complex. 
These  allow  developers  to  control  the  content  of  conforming  documents  more 
rigidly.  When  describing  an  element  in  a  schema  as  a  complex  type  that  element 
may  contain  other  elements,  attributes,  or  both.  Sometimes  when  designing 
XML  Schema,  we  need  to  design  our  own  data  types.  To  do  this,  we  may  use 
either  complex  or  simple  type  definitions.  Simple  type  definitions  use  an  existing 
data  type  in  the  XML  language  as  their  base  or  another  user-defined  data  type. 
Simple  type  definitions  are  sometimes  called  derived  types  (Hunter  and  others, 
2003). 

All  XML  documents  must  start  with  a  root  element,  and  since  XML 
Schema  are  a  specific  type  of  XML  document  they  have  a  specific  root  element. 
For  most  XML  Schema  the  word  schema  is  the  root  element  and  to  ensure 
uniqueness  the  namespace  prefix  xsd  is  commonly  used.  Generally,  after  the 
root  element  of  the  schema,  the  root  element  of  the  document  is  identified.  To 
develop  a  schema,  it  is  important  to  first  know  what  the  result  document  needs  to 
look  like.  Appendix  B  shows  what  the  result  document  may  look  like  here.  As 
was  mentioned  in  the  introduction,  schema  allow  for  flexibility  in  what  the  result 
document  looks  like  that  validates  against  them.  This  design  decision  allows  for 
information,  albeit  sometimes  incomplete,  to  still  be  of  some  use  to  the 
application. 

Appendix  A  provides  the  governing  structure  for  the  result  document.  The 
ability  to  extract  information  from  the  UOB  databases  in  XML  format  eliminates 
the  need  to  develop  a  result  document  by  hand.  Initial  failed  attempts  at 
extracting  information  from  the  UOB  database  resulted  in  the  author’s 
development  of  a  schema  and  result  document  which  closely  resembles  the  ones 
extracted  from  the  UOB  version  7.7.  While  the  schema  and  result  documents 
are  similar,  several  important  differences  exist.  These  differences  are  discussed 
now. 
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1.  Schema  Compared 

Any  document  to  be  validated  against  the  author’s  schema  found  in 
Appendix  E  must  have  a  root  element  called  UnitData .  From  there  the 
schema  defines  the  structure  of  the  result  document  beginning  with  the 
administrative  data  of  the  unit.  Both  complex  and  simple  types  of  definitions  are 
necessary  to  describe  the  information  using  the  XML  language.  The  author’s 
schema  provides  an  outer  structure  for  the  document  by  using  one  all- 
encompassing  complex  type  definition.  This  definition  includes  multiple  elements 
that  make  up  the  rest  of  the  structure.  Figure  17  shows  a  portion  of  this 
structure.  Two  of  the  elements  inside  the  complex  type  definition  require  the  use 
of  additional  simple  type  definitions.  In  Figure  17  only  the  simple  type  definition 
for  the  Unit  Level  Code  element  is  shown. 

These  simple  type  definitions  are  required  because  enumerated  lists  are 
necessary  to  describe  all  of  the  valid  data  values  that  may  occupy  the  element  in 
this  XML  document.  They  restrict  the  element  data  in  the  document  to  be  of 
base  string  and  then  use  the  xs  :  enumeration  element  in  the  schema  to 
elaborate  on  the  exact  items  allowed  inside  this  element  in  the  result  document. 
This  accomplishes  two  things.  First  it  prevents  incorrect  information  from  being 
accepted  in  the  result  document  (no  undefined  enumeration  strings  are  allowed). 
Second,  it  assists  the  document’s  author  to  see  exactly  what  data  is  considered 
acceptable  in  these  elements.  The  remaining  elements  inside  the  complex  type 
definition  allow  plain  strings  and  are  not  as  restrictive  to  the  nature  of  what  these 
strings  must  say.  Compared  to  the  (JOB  version  7.7  schema  in  Appendix  A,  the 
author’s  schema  is  much  more  restrictive.  This  is  an  example  of  where  a 
developer  under  time  constraints  has  the  flexibility  to  be  lenient  as  to  what  he 
allows  to  be  accepted  as  valid  XML  content.  Time  permitting  either 
enumerations  or  simple  type  definitions  using  patterns  and  other  built-in  XML 
data  types  might  replace  these  simple  strings  to  provide  even  more  stringent 
control  of  the  information  in  the  XML  document. 

After  the  administrative  data,  information  about  the  unit’s  personnel  is 

expected.  For  this  another  complex  type  element  named  Personnel  is  used 
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and  required  in  the  XML  document.  It  contains  the  definition  for  the  elements 
containing  information  about  job  descriptions,  military  ranks,  military  occupational 
specialties,  numbers  authorized,  numbers  on  hand,  etc.  Again,  enumerated  lists 
and  simple  type  definitions  are  used  to  best  describe  this  data.  The  simple  type 
definition  used  here  is  different  however.  This  time  the  built-in  data  type  called 
pattern  is  used.  This  data  type  allows  the  document  author  to  specify  the 
exact  string  pattern  in  terms  of  letters,  numbers  etc.  allowed  inside  the  element. 
Figure  18  shows  the  portion  of  the  author’s  schema  that  uses  the  pattern  data 
type  for  defining  the  content  of  the  MilitaryOccupationSpecialityCode 
element. 


Example  simpleType 


Example  enumeration 


<xs:element  name="AdministrativeUnitlnformation"> 
<xs:complexType> 

<xs:sequence> 

<xs:element  name="ParentUIC"  type=''xs:string"/> 
<xs:element  name="ParentUTC"  type="xs:string"/> 
<xs:element  name="ParentULC"  type="xs:string"/> 
<xs:element  name="SRC"  type="xs:string"/> 
<xs:element  name-'UnitUIC"  type="xs:string"/> 
<xs:element  name="UnitName"  type="xs:string"/> 
<xs:element  name-'UnitTypeCode"  type="xs:string"/> 
<xs:element  name="UnitLevelCode''> 
<xs:simpleType> 

<xs:restriction  base="xs:string"> 
<xs:enumeration  value="SEC"/> 
<xs:enumeration  value="SQD"/> 
<xs:enumeration  value="PLT7> 
<xs:enumeration  value="HFT"/> 
<xs:enumeration  value="TRP"/> 
<xs:enumeration  value="CO'7> 
<xs:enumeration  value="SQ7> 
<xs:enumeration  value="BN"/> 
xs:enumeration  value="REG7> 
<xs:enumeration  value="BDE''/> 
<xs:enumeration  value="DIV"/> 
<xs:enumeration  value="CPS7> 
<xs:enumeration  value="A7> 
</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 


Figure  17.  Example  enumeration  used  to  specifically  define  what  is  allowed 
within  the  UnitLevelCode  element  of  the 

AdministrativeUnit Inf ormation  element. 
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<xs:element  name="MilitaryOccupationSpecialityCode"> 

<xs:simpleType> 

<xs:restriction  base="xs:string''> 

<xs: pattern  value="[0-9]{2}[A-Z]{1  }([0-9]{2}|[0-9]{1  }[A-Z]{1  })"/> 
</xs:restriction> 

</xs:simpleType> 

</xs:element> 


Figure  18.  An  example  of  the  XML  pattern  data  type  in  use. 

The  pattern  structure  seen  above  allows  for  the  first  two  digits  of  the 
pattern  to  be  numbers  between  zero  and  nine.  The  next  digit  has  to  be  one  letter 
from  A-Z.  The  third  and  fourth  digits  are  two  more  numbers  from  zero  through 
nine  or  can  be  just  one  number  between  zero  and  nine  and  one  letter  between  A 
and  Z.  This  is  much  different  from  the  conventions  used  in  the  (JOB  schema. 

The  UOB  schema  is  not  this  restrictive  and  simply  allows  any  string  to  be  used 
inside  this  element.  The  loose  structure  of  the  UOB  version  7.7  schema  invites 
difficulties  when  it  uses  the  less  restrictive  data  types. 

In  order  to  restrict  anyone  from  filling  in  “none”  as  a  valid  value  for  the 
three  elements  of  number  authorized,  on  hand,  and  required,  the  element 
content  is  restricted  to  a  type  of  non-negative  integer  (see  Figure  19).  In  XML, 
this  indicates  that  the  numbers  0  through  9  are  completely  acceptable  but  no 
negative  numbers  are  allowed  and  because  the  data  must  be  a  number,  the  input 
of  strings  will  cause  an  error  during  XML  validation,  such  as:  “This  file  is  not  valid: 
Invalid  value  for  database  type  nonNegativelnteger  in  element  ‘numberRequired’” 
(generated  by  XMLSPY  Enterprise  Edition). 


<xs:element  name-'NumberRequired"  type="xs:nonNegativelnteger"/> 
<xs:element  name="NumberAuthorized"  type-'xs:nonNegativelnteger"/> 
<xs:element  name="NumberOnHand"  type="xs:nonNegativelnteger"/> 


Figure  19.  Example  Non-negative  Integer  type  use  in  Appendix  E. 


The  last  piece  of  XML  Schema  developed  by  the  author  (Appendix  E) 
involves  the  unit  equipment.  The  unit  equipment  element  is  a  complex  type 
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element  and  includes  those  fields  listed  in  the  equipment  file  from  UOB  DAT. 

The  use  of  the  pattern  data  type  again  assists  in  ensuring  that  the  equipment 
codes  are  in  the  correct  format.  Non-negative  integers  in  the  other  elements  of 
the  complex  type  ensure  no  improper  string  usage.  Once  this  step  is  complete, 
the  schema  is  complete  and  it  is  then  checked  to  ensure  that  it  is  well-formed, 
xml  valid  and  XML  Schema  valid  using  the  XML  authoring  tool  XMLSPY  by 
Altova. 

2.  Document  Development 

Given  a  complete  schema  an  author  has  numerous  software-tool  options 
for  generating  a  new  XML  document.  Outside  of  trivial  examples,  authors  will 
generally  use  software  to  generate  data  files.  Some  XML  authoring  tools  can 
auto  generate  example  documents  if  valid  schemas  exist.  Generated  documents 
can  be  useful  to  developers  for  revealing  flaws  in  a  schema.  Autogeneration  also 
saves  time.  When  used,  the  document  author  simply  is  required  to  fill  in  the 
content  of  his  document.  This  research  effort  used  both  approaches.  XMLSPY 
generated  one  document,  which  was  used  to  check  the  author’s  design  idea  for 
Appendix  E.  This  uncovered  several  problems  namely  in  the  authors  use  of 
patterns  and  enumerated  lists. 

Although  the  structure  of  the  schema  in  Appendix  E  was  inspired  by  the 
UOB  DAT,  it  is  a  more  rigidly  structured  document  than  the  UOB  version  7.7 
schema  provided  in  Appendix  A.  The  reader  should  notice  that  although  the 
Unit.xsd  file  does  not  fully  encompass  all  NATO  country-specific  information  it 
does  enforce  more  rigid  standards  for  things  such  as  equipment  and  MOS  codes. 
The  more  rigid  structure  ensures  that  the  data  being  passed  is  in  the  correct 
format  which  creates  a  more  stable  environment.  The  permissive  use  of  invalid 
strings  for  information  may  allow  incorrect  or  false  information  to  be  accepted  into 
an  application,  subsequently  causing  false  outcomes  or  (even  worse)  fatal  errors 
during  execution.  Such  mission-critical  errors  are  avoidable  through  careful 
schema  design. 
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C.  XSLT  DOCUMENT  DEVELOPMENT 
1.  General  Information 

Using  XSLT  to  transform  XML  documents  is  a  powerful  and  difficult 
endeavor.  The  reason  for  this  is  clear.  We  are  attempting  to  take  a  source 
document  with  specific  information  governed  by  one  schema,  and  precisely 
transform  it  into  a  generic  form  of  the  same  data  governed  by  a  much  different 
schema,  in  such  a  way  as  to  allow  different  applications  to  use  the  corresponding 
data  with  consistent  semantics.  Many  transformations  may  be  necessary  for 
legacy  models  and  simulations  but  if  a  standard  method  and  model  of 
representation  (i.e.  ontology)  are  established  then  future  models  and  simulations 
are  likely  to  have  less  difficulty  interchanging  data. 

XSLT  stands  for  Extensible  Stylesheet  Language  for  Transformations 
(Kay,  2003).  It  is  another  language  in  the  growing  family  of  XML  languages  used 
in  this  case  to  transform  one  type  of  XML  document  into  another.  XSLT  is  not 
just  for  producing  other  XML  documents.  It  also  can  be  used  to  generate  HTML 
and  databases  of  different  sorts  from  an  XML  document.  It  has  the  ability  to 
transform  XML  documents  into  other  XML  documents  and  to  transform  XML  into 
plain  text.  It  cannot,  however,  transform  plain  text  into  XML.  XSLT  uses  a  two 
stage  approach  to  transform  XML  documents. 

The  first  stage  is  a  structural  transformation,  in  which  the  data  is 
converted  from  the  structure  of  the  incoming  XML  document  to  a 
structure  that  reflects  the  desired  output.  The  second  stage  is 
formatting,  in  which  the  new  structure  is  output  in  the  required 
format  such  as  HTML  or  PDF  (Kay,  2003,  14). 

XML  and  XSLT  use  an  abstract  data  structure  called  a  tree  to  represent 
document  content.  Source  trees  are  formed  from  the  initial  XML  document 
through  parsing  and  result  trees  are  formed  by  the  XSLT  parser  through 
serialization.  As  a  result  of  the  use  of  trees,  there  is  no  single  API  or  data 
representation  of  the  contents  of  the  tree,  only  a  conceptual  model  that  defines 
the  objects  in  the  tree,  their  properties  and  their  relationships  to  one  another 
(Kay,  2003).  When  referring  to  the  result  tree,  reference  is  being  made  to  the 
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structure  and  content  rather  than  format.  Reference  to  the  result  document 
indicates  that  the  result  tree  is  in  the  form  of  an  XML  document  or  other  readable 
document  form  specified.  Two  methods  of  structuring  data  in  the  result  tree  are 
through  the  use  of  built-in  templates  or  through  the  use  of  user  developed 
templates.  In  the  XSLT  language,  the  xsl :  template  element  defines  a 
template  rule.  This  rule  is  triggered  when  a  matching  portion  of  the  source  XML 
document  is  processed  by  the  XML  parser.  The  “match”  attribute  of  the 
xsl :  template  element  identifies  a  pattern  to  be  used  from  the  source 
document  node  tree. 

To  begin  any  transformation  process  a  template  must  typically  be  applied 
to  the  root  node  of  the  source  document.  The  root  element  is  identified  by  setting 
the  match  attribute  equal  to  the  forward  slash  character  (/).  If  the  XSLT  parser 
does  not  find  this  explicit  statement,  it  will  use  a  built-in  template  to  handle  this 
situation.  Templates  consist  of  elements  and  text  nodes.  Elements  in  the 
template  may  either  be  classified  as  instructions  or  data  depending  on  their 
namespace.  When  a  template  is  instantiated  the  instructions  within  that  template 
are  applied  to  the  source  document  and  the  data  nodes  are  copied  to  the  result 
tree.  For  the  purposes  of  this  work,  the  result  tree  is  then  formatted  into  an  XML 
document. 

After  the  root  template  match,  additional  templates  are  necessary  to 
transform  each  part  of  the  source  document  into  the  desired  result  document. 
This  XSLT  uses  a  C2IEDM  file  as  the  source  file  and  transforms  all  usable  data 
extracted  into  a  (JOB  compliant  document  to  be  used  as  initialization  information 
for  simulations  in  the  FAST  Toolbox.  The  following  excerpt  generally  describes 
the  basic  structure  for  a  document  that  is  compliant  with  the  C2IEDM. 

C2IEDM  structure  labels  class  objects  as  object-type  and 
individually  identified  instances  as  object-item.  Implicit  in  the 
distinction  between  type  and  item  is  the  assumption  that  data 
relating  to  object-types  will  tend  to  be  static  (i.e.,  the  values  of 
the  attributes  are  not  likely  to  change  very  often  over  time), 
whereas  the  values  of  attributes  of  object- items  are  likely  to  be 
more  dynamic.  For  example,  if  a  characteristic  is  about  a  type 
(e.g.,  M1A1  Abrams  Tank),  it  is  an  attribute  of  object-type. 
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Thus,  calibre  of  main  gun,  track  width,  and  load  class  are 
characteristics  of  object-type.  However,  the  call  sign,  actual  fuel 
level,  munitions  holdings,  and  current  operational  status  of  a 
specific  tank  are  characteristics  of  an  object-item  (NATO,  2002, 

9). 

The  result  document  generated  here  does  not  use  this  structure  nor  does 
it  use  these  names  for  its  elements.  Instead  it  follows  its  own  schema  which  is 
uniquely  different.  A  (JOB  version  7.7  schema-compliant  document  for  unit  data 
is  partially  shown  in  Figure  20.  Upon  review  it  can  be  seen  that  the  structure  is 
significantly  different  from  the  C2IEDM  structure  description  given  above. 
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?xml  version="1.0"  encoding=”UTF-8"?> 

<UOB  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:noNamespaceSchemaLocation="UOB  Schema 
7.7.xsd"> 

<ForceStructurelnformation> 

<Name/> 

<FileName/> 

<Description/> 

<Purpose/> 

<CreatedBy/> 

<CreationDate>2004-04-15</CreationDate> 

<LastModifiedBy/> 

<LastModifiedDate>2004-04-15</LastModifiedDate> 

</ForceStructurelnformation> 

<Relationships> 

<Relationship  type="Operational  Control"> 

<Assigned> 

<UnitNode  UIC="WG2LA0"/> 

</Assigned> 

</Relationship> 

</Relationships> 

<Units> 

<Unit  UIC="WG2LA0"  dataSource="ARMYTOE"> 

<Name>1ST  SQDN  3D  ARMORED  CAVALRY,  A  CAV  TRP,  CAV  SQDN</Name> 

<TypeCode>  </TypeCode> 

<LevelCode>  </LevelCode> 

<TotalPersonnel> 

<Authorized>1 32</Authorized> 

<OnHand>132</OnHand> 

</TotalPersonnel> 

<SRC> 

<Code>17487L000</Code> 

<Name>CAV  TRP,  CAV  SQDN</Name> 

</SRC> 

<OpfacRule> 

<Code>AB200</Code> 

<Title>AR  CO/CAV  TRP  CDR  (TRACK)</Title> 

</OpfacRule> 

<SymbolCode>S*G*UCRVA-*****</SymbolCode> 

<Resource> 

<Personnel  code=”92Y30"> 

<Description>SUPPLY  SGT </Description> 

<Grade>E6</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code="19K10"> 

<Description>TANK  CREWMAN</Description> 

<Grade>E4</Grade> 

<Required>9</Required> 

<Authorized>9</Authorized> 

</Personnel> 

<Equipment  code="T13305"> 

<Description>TANK  COMBAT  FULL  TRACKED:  120MM  GUN  Ml A2</Description> 
<Required>9</Required> 

</Equipment> 

<Equipment  code="F60530"> 

<Description>FIGHTING  VEHICLE:  FULL  TRACKED  CAVALRY  HI  SURVIVABILITY 
(CFV)</Description> 

<Required>13</Required> 

</Equipment> 

</Resource> 

</Unit> 

</Units> 

</UOB> 


Figure  20.  Example  of  a  partial  unit  document  extracted  from  (JOB  version  7.7. 

The  following  table  depicts  for  the  reader  the  association  between  the 
elements  of  the  UOB  schema  and  the  locations  where  the  data  was  found  in  the 
C2IEDM.  The  paths  to  the  data  locations  are  shown  using  the  XPath  language. 
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A  careful  review  of  and  frequent  consultation  with  this  table  while  reading  the 
remainder  of  this  chapter  will  greatly  assist  the  reader  in  understanding  the 
development  described.  This  table  provides  the  beginning  for  a  complete  round- 
trip  mapping  of  the  UOB  and  the  C2IEDM  in  what  is  believed  to  be  a  lossless 
manner.  The  following  is  provided  to  enhance  the  understanding  of  the  table 
below.  Attributes  directly  follow  the  element  they  are  assigned  to.  Some 
elements  have  more  than  one  attribute.  The  word  “None”  indicates  that  no 
correspondence  was  found  between  the  C2IEDM  and  the  UOB  for  that  element 
or  attribute.  The  word  “Unknown”  indicates  that  there  may  be  a  correspondence 
but  that  the  author  was  unable  to  locate  it. 


Table  1 .  Table  of  correspondences  between  the  elements  in  the  UOB  schema  and 
the  XPath  expressions  pointing  to  the  location  of  the  data  in  the  C2IEDM. 


Table  of  Correspondences  between  UOB  and  C21EDM 

Elements  and  Attributes  from 
the  Unit  Order  of  Battle  (UOB) 
schema 

Attributes  in  BOLD  font 

Command  and  Control  Information  Exchange  Data  Model 
(C2IEDM) 

XPath  expressions  to  data  for  UOB  elements  shown  in 

Courier  New  font 

UOB 

None 

ForceStructurelnformation 

None 

Units 

None 

Name 

None 

FileName 

None 

Description 

None 

Purpose 

None 

CreatedBy 

None 

CreationDate 

None 

LastModifiedBy 

None 
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Table  of  Correspondences  between  UOB  and  C21EDM 


LastModifiedDate 

None 

Unit* 

/BattlespaceData/ OBJECT-ITEM/ ORGAN I SAT I ON /UN IT 

*  depends  on  whether  looking 
at  item  or  type 

/BattlespaceData/ OBJECT-TYPE/ ORGANISATION- 
TYPE  /UNIT-TYPE 

UIC 

Unknown 

dataSource 

None 

Name 

/BattlespaceData/ OBJECT- 

ITEM/ 0 RGANIZAT ION/UNIT /uni t-formal-abreviated- 

name 

Present 

/BattlespaceData /LOCATION /POINT/ 

Name 

Unknown 

Latitude 

/BattlespaceData/LOCATION/ POINT /ABSOLUTE- 
POINT/  absolute-point/ absolute-point-latitude- 
coordinate 

Longitude 

/BattlespaceData/LOCATION/ POINT /ABSOLUTE- 
POINT/  absolute-point/ absolute-point-longitude- 
coordinate 

DescriptionCode 

/BattlespaceData/ OBJECT-TYPE/ ORGANISATION- 
TYPE/  GOVERNMENT -ORGAN I SAT I ON- TYPE /MIL I TARY- 
ORGANISATION-TYPE/UNIT-TYPE/unit- type-category- 
code 

LevelCode 

/BattlespaceData/ OBJECT-TYPE/ ORGANISATION- 
TYPE/  GOVERNMENT -ORGAN I SAT I ON- TYPE /MIL I TARY- 
ORGANI SAT ION-TYPE /UNIT-TYPE /unit- type- size-code 

Resource* 

/BattlespaceData/ OBJECT -ITEM/ HOLDING 

*  depends  on  whether  looking 
at  item  or  type 

/BattlespaceData/ OBJECT -TYPE /HOLDING 

Personnel* 

/BattlespaceData/ OBJECT -ITEM/ HOLDING 

*  depends  on  whether  looking 
at  item  or  type 

/BattlespaceData/ OBJECT -TYPE /HOLDING 

code 

/BattlespaceData/ OBJECT-TYPE/ob j  ect-type-name 

Description 

Unknown 
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Table  of  Correspondences  between  UOB  and  C21EDM 

Grade 

/BattlespaceData/OBJECT-TYPE/ PERSON-TYPE /person- 
type  -rank-  code 

Required* 

/BattlespaceData/ OBJECT -ITEM/ HOLDING/ holding- 
operational  -quantity 

*  depends  on  whether  looking 
at  item  or  type 

/BattlespaceData/ OBJECT -TYPE /HOLDING/ holding- 
operational  -quantity 

Authorized* 

/BattlespaceData/ OBJECT -ITEM/ HOLDING/ holding- 
total  -quantity 

*  depends  on  whether  looking 
at  item  or  type 

/BattlespaceData/ OBJECT -TYPE /HOLDING/ holding- 
total  -quantity 

Equipment 

/BattlespaceData/ OBJECT -TYPE /MATERIEL- 
TYPE  /EQUIPMENT  -TYPE 

code 

/BattlespaceData/ OBJECT - TYPE /obj  ect- type -name 

Required* 

/BattlespaceData/ OBJECT -ITEM/ HOLDING/ holding- 
operational  -quantity 

*  depends  on  whether  looking 
at  item  or  type 

/BattlespaceData/ OBJECT -TYPE /HOLDING/ holding- 
operational  -quantity 

Authorized* 

/BattlespaceData/ OBJECT -ITEM/ HOLDING/ holding- 
total  -quantity 

*  depends  on  whether  looking 
at  item  or  type 

/BattlespaceData/ OBJECT -TYPE /HOLDING/ holding- 
total  -quantity 

2.  Force  Structure  Information 

After  reviewing  the  schema  governing  the  result  document,  the  XSLT 
transformation  process  begins  using  a  template  that  simply  outputs  the 
administrative  information  for  the  unit  which  is  called 

ForceStructurelnformation  in  the  result  document.  This  section  includes 
information  about  the  document  like  the  unit  name  and  when  the  document  was 
created  or  modified.  Figure  21  shows  this  template  and  the  XSLT  rule  that  calls 
it.  Several  templates  are  needed  to  fully  extract  all  information  about  the  unit  in 
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question  from  the  C2IEDM  model.  Those  templates  deal  with  unit  data, 
personnel  data  and  equipment  data. 


<xsl:call-template  name="FileHeader"/> 

<xsl:template  name="FileHeader"> 

<xsl:element  name="Name"/> 

<xsl:element  name="FileName"/> 

<xsl:element  name="Description">Document  generated  using  XSLT  on  XML  C2IEDM  Ver6.1  model</xsl:element> 
<xsl:element  name="Purpose"/> 

<xsl:element  name="CreatedBy">C2IEDM  From  Command  and  Control  System</xsl:element> 

<xsl:element  name="CreationDate'7> 

<xsl:element  name="LastModifiedBy"/> 

<xsl:element  name=''Lastl\/lodifiedDate7> 

</xsl:template> 


Figure  21 .  XSLT  template  used  to  extract  ForceStructurelnformation  from 

C2IEDM. 

Figure  22  shows  the  results  of  the  XSLT  used  above.  This  portion  of  the 
stylesheet  is  very  easy  to  understand  and  requires  little  processing  on  the  part  of 
the  XSLT  processor  because  no  computations  are  being  conducted.  The 
instructions  given  to  the  parser  are  to  simply  create  the  elements  listed  above 
and  output  them  as  seen  below. 


<ForceStructurelnformation> 

<Name/> 

<FileName/> 

<Description>Document  generated  using  XSLT  on  XML  C2IEDM  Ver  6.1  model</Description> 
<Purpose/> 

<CreatedBy>C2IEDM  From  Command  and  Control  System</CreatedBy> 

<CreationDate/> 

<LastModifiedBy/> 

<LastModifiedDate/> 

</ForceStructurelnformation> 


Figure  22.  ForceStructurelnformation  output  of  XSLT  of  C2IEDM. 

3.  Unit  Identification 

To  begin  the  transformation  of  unit  identification  data  a  handle  is  required 
for  each  unit  contained  in  the  C2IEDM  model.  Once  the  handle  is  obtained, 
using  it  to  assist  in  the  traversal  of  the  model  provides  a  relative  amount  of 
certainty  that  the  information  extracted  belongs  to  the  unit  assigned  the  handle. 
The  handles  used  for  traversing  the  C2IEDM  are  the  object-item-id  and 
object-type-id.  These  are  extracted  from  the  C2IEDM  when  the  template 
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shown  in  Figure  23  is  called  to  obtain  the  unit’s  name.  This  is  done  for  two 
reasons.  First  it  ensures  that  the  ids  are  attached  to  that  particular  unit  and  no 
other.  Second  obtaining  the  id’s  at  this  level  and  saving  them  into  variables 
allows  them  to  be  passed  into  other  templates. 


<xsl : template  match  =  "unit-formal-abbreviated-name"> 

<xsl:element  name="Unit"> 

<xsl:attribute  name="UIC"  /> 

<xsl:attribute  name="dataSource"  /> 

<xsl:element  name="Name"> 

<xsl:value-of  select="."  /> 

</xsl:element> 

<xsl:variable  name="ObjectItemID"  select=". ./../. ./object-item-id"  /> 

<xsl:variable  name  =  "ObjectTypeID"  select="../../../OBJECT-ITEM-TYPE/object-type-id"  /> 
<xsl:call-template  name="RelativeUnitLocation"> 

<xsl:with-param  name="UnitObjectItemID"  select="$ObjectItemID"  /> 

<xsl:with-param  name="UnitObjectItemLocationID"  select=".. /../.. /OBJECT- ITEM- 
LOCATION/location-id"  /> 

</xsl:call-template> 

<xsl:call-template  name="UnitTypeCategoryCode"> 

<xsl:with-param  name="OTypeID"  select="$ObjectTypeID" /> 

</xsl:call-template> 

<xsl:call-template  name="UnitTypeSizeCode"> 

<xsl:with-param  name="ObjTypID"  select="$ObjectTypeID" /> 

</xsl:call-template> 

<xsl:element  name="Resource"> 

<xsl:call-template  name="PersonnelHoldings"  /> 

<xsl:call-template  name="EquipmentHoldings"  /> 

</xsl:element> 

</xsl:element> 

</xsl:template> 


Figure  23.  Main  template  used  within  the  XSLT  to  extract  unit  information  from 

the  C2IEDM. 


In  order  to  extract  the  unit’s  name,  the  parser  is  directed  to  follow  the  path 
in  the  apply-templates  call.  The  select  attribute  of  the  xsl :  value-of  element 
extracts  the  name  of  the  unit  and  acts  as  the  starting  point  for  the  rest  of  the 
transformation.  From  there  the  parser  is  instructed  to  back  up  three  levels  to 
extract  the  object-item-id  from  the  object-item  element  and  the 
object-type-id  from  the  OBJECT-ITEM-TYPE  element.  Once  this  is 
complete  the  handles  for  the  object-item  and  object-type  are  set.  Figure  24 
shows  an  XMLSpy  grid  view  of  part  of  the  BIXS  containing  the  object- item, 
object-type  and  unit  elements  of  the  model. 
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REPORTING-DATA  and  to 
dfetinguish  it  from  al  other 
REPORTING-DATAs. 


Figure  24.  Grid  view  of  BIXS  containing  object-item-id,  OBJECT-ITEM- 

TYPE  and  unit  constructs. 

4.  Personnel  Identification  and  Extraction 

Figure  23  includes  two  template  calls,  one  for  Personnel  holdings  and  one 
for  Equipment  holdings.  The  extraction  and  formatting  of  the  personnel  holdings 
is  discussed  in  this  section.  The  (JOB  version  7.7  schema  dictates  that 
personnel,  equipment  and  aircraft  are  used  as  resources  as  can  be  seen  in 
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Figure  25.  This  thesis  is  focused  on  Personnel  and  Equipment  holdings  of  a 
specific  U.S.  Army  unit  that  contains  no  aircraft.  Recommended  future  work 
includes  increasing  the  robustness  of  this  XSLT  to  include  all  equipment  specific 
to  the  U.S  Navy,  Air  Force,  Marines  and  Coast  Guard. 


p--j  Personnel  [+1 

'vriViYiYiW  1 

0..x 

— - —  . 

:  :r  ::  r  he:_  :e:e 

Equipment  [+] 

v - 

This  is  a  grouping  eefnent 

0..0D 

:  E: _  ;  r  ae:_  :e  :  =  := 

L--i  Aircraft  |+] 

m3 

0..x 

This  is  a  container  eement 
for  Aircraft  resource  data. 

Figure  25.  Resource  construct  found  in  UOB  schema. 

The  expanded  personnel  information  included  in  the  target  UOB  schema 
is  shown  in  Figure  26.  Not  all  of  this  information  is  required  to  initialize  a 
simulation  or  can  be  found  within  a  command  and  control  system.  The  items 
focused  on  here  are  the  Description,  Grade,  (Quantity)  Required  and 
(Quantity)  Authorized  elements.  These  are  items  that  are  extractable  from 
the  C2IEDM.  Recommendations  for  national  modifications  to  the  C2IEDM  to 
include  more  specifics  about  personnel  are  being  made  to  the  MIP  through  works 
such  as  this  thesis. 

Resources  in  the  UOB  are  classified  as  holdings  in  the  C2IEDM  as 
shown  in  Figure  27.  In  order  to  extract  information  from  the  C2IEDM  pertaining 
to  personnel  three  templates  are  called.  First  is  the  PersonnelHoldings  template 
seen  in  Figure  28,  the  second  is  the  PersonnelTemplate  seen  in  Figure  29  and 
the  third  is  the  PersonnelHoldingNumbers  in  Figure  30.  The  PersonnelHoldings 
template  instructs  the  XSLT  processor  to  backup  from  its  current  location  where 
the  formal  unit  name  was  obtained,  to  the  holding  element  of  the  C2IEDM 
model.  There  it  extracts  the  holding  object-type-id  for  each  holding  and 
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places  them  into  a  temporary  variable  called  holdingOb j  ectTypeiD.  This 
variable  is  then  compared  to  the  ob j  ect-type-ids  from  each  of  the  object- 
type  elements.  Two  tests  are  then  conducted  to  ensure  that  the  holdings  are  for 
the  same  specified  object- item  and  are  coded  as  personnel  objects.  Once 
those  two  tests  are  passed  the  XSLT  processor  outputs  the  structure  for  the 
result  document  and  the  contents  found  in  the  C2IEDM  model.  The 
xsl :  value-of  element  with  select  attribute  located  inside  the  attribute 
named  code  selects  the  MOS  name  of  the  object-type  from  the  C2IEDM 
structure. 

The  PersonnelTemplate  is  responsible  for  extracting  the  Grade 
information  necessary  for  the  result  document.  When  this  template  is  called  it 
maintains  the  scope  of  the  PersonnelHoldings  template.  This  means  that  the 
scope  of  the  object-item-id  and  object-type-id  are  not  lost  which  again 
helps  ensure  that  the  information  being  tested  for  and  extracted  is  connected  to 
the  personnel  holdings  of  the  unit  being  examined.  Currently,  the  C2IEDM 
merges  officer  ranks  of  Ol’s  and  02’s  together  in  one  grade  called  OF1 . 
Additionally,  enlisted  ranks  above  E 7  Sergeant  First  Class  and  Warrant  Officer  2 
do  not  exist.  While  this  is  adequate  for  many  other  countries  it  is  not  acceptable 
for  the  US  military  and  additional  ranks  are  necessary.  Upon  U.S. 
implementation  of  the  C2IEDM  as  the  standard  data  interchange  model,  a 
national  extension  would  be  required  to  encompass  these  additional  rank 
requirements.  Instructions  pertaining  to  the  election  of  model  extensions  can  be 
found  on  the  MIP  website  in  the  documentation  section  under  the  Guide  to 
Change  Proposals  (CP)  (MIP,  2004a). 
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r--f  Description  ; 

The  description  of  a  mitary 
occupational  specialty  code 
of  a  person  in  a  mftary  unit 
This  field  is  not  used  in 
MIDB. 


|---!=Grade 


This  is  a  container  eene": 
for  Person rve  resource  dati 


Pay  grade  of  personnel 
assg”ed  to  a  unit.  This 
field  s  not  used  in  MIDB. 


;  Required  ! 

For  US  units  this  is  the 
quantity  of  personnel 
recu  red  by  the  Unit  to 
perform  te  wartime  mission 
For  MIDB  units  this  is 
relative  to  the  parent  entity 
the  total  number  of  mitary 
personae  assessed  to  be 
war  authorized  (WA). 


;  Authorized  • 

For  US  units  this  ts  the 
quantity  of  personnel  to  be 
assg-ed  to  the  Unit  to 
perform  its  peacet  me 
mission.  For  MIDB  units 
this  is  relative  to  the  parent 
entity,  the  total  number  of 
mikary'  personne  assessed 
to  be  peaceti  me  authorized 
(PA). 


'OnHand 


■ 


For  US  units  this  6  the 
quantity'  of  personnel  present 
for  duty  in  the  unit.  For 
MIDB  units  this  is  relative  to 
the  parent  entity,  the  total 
number  of  mitary  personnel 
assessed  to  be  on-hand 
(OH). 


Figure  26.  Expanded  Personnel  element  found  in  (JOB  schema. 
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object-item-id 


The  unique  value,  or  set  of 
chararders.  assg"ed  to 
netrese":  a  specif c 
OBJECT-ITEM  and  to 
distinguish  it  from  at  other 
OBJECT-ITEMs. 


object-type-id 


The  unique  value-  or  set  of 
characters,  assgred  to 
represent  a  speafic 
OBJECT-TYPE  and  to 
distinguish  it  from  all  other 
OBJECT-TYPEs. 


HOLDING  E 


The  quantity  of  each  spedfic 
OBJECT-TYPE  that  is  held 
by',  installed  tn,  or  included 
with  a  specific 
OBJECT-ITEM. 


& 


holding-index 


The  unique  value  or  set  of 
characters,  assg-ed  to 
represe-.t  a  specific 
HOLDING  for  a  spedfic 
OBJECT-ITEM  and  a 
spedfic  OBJECT-TYPE  a"d 
to  distinguish  it  from  ali  other 
HOLDINGS  for  that 
OBJECT-ITEM  and  that 
OBJECT-TYPE. 


holding-operational-quantity 


The  non-monetary  numeric  value 
represe-t-g  n  a  specific  HOLDING  the 
perceived  count  of  specific 
OBJECT-TYPEs  that  are  in  operational 
status. 


holding-total-quantity 


The  non-monetary  numeric 
value  represer'f’g  in  a  specific 
HOLDING  the  perceived  total 
count  of  specific 
OBJECT-TYPEs. 


reporting-data-id  | 

The  unique  valuer  or  set  of 
characters,  asdgned  to 
represent  a  specific 
REPORTING-DATA  and  to 
distinguish  it  from  all  other 
REPORTING-DATAs. 


HOLDING  construct  found  within  the  C2IEDM. 
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Figure  27. 


<xsl: template  name="Personnel  Holdings'^ 

<xsl:for-each  select="../../../HOLDING"> 

<xsl: variable  name="holdingObjectTypeID"  select="object-type-id"  /> 

<xsl: variable  name="holdingObjectItemID"  select="object-item-id"  /> 
<xsl:for-each  select= /OBJ ECT-TYPE"> 

<xsl: variable  name="objectTypeID'  select="object-type-id"  /> 

<xsl : if  test="$objectTypeID  =  $holdingObjectTypeID"> 

<xsl : if  test="object-type-category-code  /*  [local-name()  =  'PE']"> 
<xsl:element  name="Personnel"> 

<xsl:attribute  name="code"> 

<xsl:value-of  select="object-type-name"  /> 
</xsl:attribute> 

<xsl:call-template  name="PersonnelTemplate"  /> 
<xsl:call-template  name="PersonnelHoldingsTemplate"  /> 
</xsl:element> 

</xsl:if> 

</xsl :  if  > 

</xsl:for-each> 

</xsl:for-each> 

</xsl:template> _ 


Figure  28.  PersonnelHoldings  template  from  C2IEDM  to  UOB  XSLT. 


<xsl:template  name="PersonnelTemplate"> 

<xsl:element  name="Description"/> 

<xsl:element  name="Grade"> 

<xsl:choose> 

<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-name()  =  'OF1']',>01/02</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-nameQ  =  'OF2']">03</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-nameQ  =  'OF3']">04</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-nameQ  =  'OF4']">05</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-nameQ  =  'OF5']">06</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-nameQ  =  'OF6']">07</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-name()  =  'OF7']">08</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-name()  =  'OF8']">09</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-name()  =  'OF9']">10</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-name()  =  'OR1'],,>E1</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-nameQ  =  'OR2']">E2</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-nameQ  =  'OR3']">E3</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-name()  =  'OR4'],,>E4</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-name()  =  'OR5']''>E5</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-name()  =  'OR6'],,>E6</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-nameQ  =  'OR7']">E7</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-name()  =  'OR8'],,>W1</xsl:when> 
<xsl:when  test=''PERSON-TYPE/person-type-rank-code/*  [local-nameQ  =  'OR9']">W2</xsl:when> 
<xsl:otherwise>Unknown</xsl:otherwise> 

</xsl:choose> 

</xsl:element> 

</xsl:template> 


Figure  29.  PersonnelTemplate  template  called  within  the  PersonnelHoldings 

template  from  C2IEDM  to  UOB  XSLT. 


The  last  template  call  to  the  PersonnelHoldingNumbers  template,  instructs 
the  XSLT  processor  to  extract  the  data  held  in  the  holding-operational- 
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quantity  and  holding-total-quantity  elements  for  the  OBJECT-TYPE 

specified.  Figure  30  provides  the  template  used  for  this  operation.  An 
assumption  is  made  here  that  the  holding-operational-quantity  and  the 
holding-total-quantity  correspond  to  the  Required  and  Authorized 
portions  of  the  personnel  construct  for  the  UOB  seen  previously  in  Figure  26. 
Once  the  processor  is  finished  with  the  template  the  personnel  portion  of  the 
result  document  is  complete. 


<xsl template  name= "Personnel HoldingNumbers"> 

<xsl:element  name="Required"> 

<xsl:value-of  select="HOLDING/holding-operational-quantity"  /> 
</xsl:element> 

<xsl: element  name="Authorized"> 

<xsl:value-of  select="HOLDII\IG/holding-total-quantity"  /> 
</xsl:element> 

</xsl:template> _ 


Figure  30.  PersonnelHoldingNumbers  template  used  to  extract  the  quantities  of 
required  and  authorized  personnel  from  the  C2IEDM. 

5.  Equipment  Identification  and  Extraction 

The  extraction  of  equipment  holdings  from  the  C2IEDM  is  more  difficult 
due  to  the  many  different  types  or  categories  of  equipment  that  the  C2IEDM 
allows.  The  unit  being  examined  in  this  work  is  an  Armored  Cavalry  unit  that 
contains  all  of  the  types  of  equipment  that  are  classified  by  the  C2IEDM  except 
for  vessels  and  railcars.  Figure  31  depicts  the  equipment  structure  required  in 
the  UOB  schema.  For  each  piece  of  equipment  in  a  unit  a  description  of  the 
piece  of  equipment,  the  required  number  of  pieces  for  the  unit,  the  authorized 
number  of  pieces  and  the  number  of  pieces  actually  on  hand  is  recorded.  While 
this  is  straightforward  enough,  the  C2IEDM  does  not  group  equipment  in  such  a 
compact  manner.  To  begin  the  traversal  of  the  C2IEDM  for  equipment,  it  is 
necessary  to  again  iterate  through  the  unit’s  holdings  found  in  the  holding 
element  of  the  model.  This  time,  a  test  is  conducted  to  see  if  the  unit  holdings 
are  of  type  materiel-type.  Equipment  is  initially  grouped  under  the 
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object-type/materiel-type  construct  in  C2IEDM.  Further  subdivisions 
occur  after  this  point  which  categorizes  equipment  as  Land-Weapon-Type, 
Aircraft-Type,  etc. 


r--|  Description  ; 

Equipment  nomendan 
associated  with  the 
equipment  code. 


Equipment  [j - (  »»«  ^0-  - 


for  Equipment  resource  data. 


;  Required  ! 

For  US  units  thsi  is  the 
quantity  of  equipment 
recured  by  the  Unit  to 
perform  its  wartime  mission 
For  MIDB  units  this  is 
relative  to  the  parent  entity 
the  total  number  of  mfttary 
equipment  assessed  to  be 
war  author  zed  (WA). 


r--j  Authorized  j 

For  US  units  the  is  the 
quantity  of  equipment!  to  tie 
assigned  to  the  Unit  to 
perform  its  peacetime 
mission.  For  MIDB  units 
this  is  relative  to  the  parent 
entity,  the  total  number  of 
mifitary  equipment  assessed 
to  be  peacetime  authorzed 
(PA). 


--  OnHand 


For  US  units  this  is  the 
quantity  of  equipment  on 
hand  in  the  unit.  For 
MIDB  units  this  is  relative  to 
the  parent  entity,  the  total 
number  of  mitary 
equipment  assessed  to  be 
orvhand  (OH). 


Figure  31 .  Equipment  construct  found  in  UOB  schema  version  7.7. 


Figure  32  shows  the  materiel-type  structure  found  in  the  C2IEDM. 
Figure  33  shows  the  first  of  three  templates  used  to  extract  equipment  resources 
from  the  C2IEDM.  The  first  template  sets  the  conditions  for  identifying  the  type 
of  holding  for  the  unit  as  that  of  materiel-type.  This  is  important  because 
holdings  in  the  C2IEDM  may  be  of  several  different  types.  Implementation  of  this 
template  begins  by  instructing  the  XSLT  parser  to  again  back  up  to  the  holding 
element  in  the  C2IEDM  maintaining  scope  and  extracting  the  object-type-id 
associated  with  the  holding.  Then  the  parser  moves  to  the  object-type 
element  and  compares  the  object-type-id  found  there  with  the  one  found  in 
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the  holding  element.  If  the  two  match  the  parser  then  checks  to  see  if  the 
category  code  found  within  that  object-type  is  of  type  ma  which  indicates 
materiel-type.  When  that  test  executes  successfully  the  template  found  in 
Figure  34  is  called  and  executed. 


— |  mate  n  el -type -icTj 

The  object-type-id  of  a 
specif*:  MATER! B.-TYPE  (a 
role  name  for 
object-type-id). 

— materiel-type-category-code  [+] 

The  specific  value  that  represents  tne 
dass  of  MATERIEL-TYPE. 


— |  materiel-type-reportable-item-t~ 

The  unformatted  character  string  that 
represens  a  specific  MATERIEL-TYPE, 
seiected  from  the  Reportable  Item  Code  £st 
issued  by  NATO. 

— I  materiel-type-stock-number-text 

The  unformatted  character  string  that 
represens  a  specific  MATERIEL-TYPE. 


-  -J  materiel-type-supply-class-code  [+) 


The  specific  value  that  represents  the  NATO 
supply  dass  of  MATERIEL-TYPE. 


MATERIEL-TYPE 


An  OBJECT-TYPE  that 
represens  equipment, 
apparatus  or  supptes  of 
mtoary  interest  without 
distinction  to  its  app  cat  on 
for  admrvistrative  or  combat 
purposes. 


j  materiel-type-maximum-height-...  | 

The  one-donensonal  near  measurement  that 
represens  the  exseme  vertical  distance 
measured  from  the  lowest  to  the  hgnesc 
reference  pomt  of  a  specific  MATERIEL-TYPE. 


j  materiel-type-maximum-length-... 

The  one-dimensional  linear  measurement  that 
represe"ts  the  exseme  horizontal  d 'stance 
measured  from  end  to  end  and  paralel  to  the 
central  axis  of  a  specific  MATERIEL-TYPE. 

|  materiel-type-maximum-width-.~ 

The  one-dimensional  linear  measurement  that 
nepresens  the  extreme  horizontal  distance 
measured  from  side  to  side  and  perpend cuLar 
to  the  centra!  axis  of  a  specific 
MATERIEL-TYPE. 


CONSUMABLE-MATERIEL-TYPE  [+] 

A  MATERIEL-TYPE  that  is  an  experda&le 
dass  of  supply. 


r  -  EQUIPMENT  -TYPE  0 
'  - . . . a 

A  MATERIEL-TYPE  that  is 
not  intended  for 
consumption. 


i---j  ORGANISATION-MATERIEL-TYPE-...  [+] 


I  0..x 

S  A  relationship  of  an  ORGANISATION  as  a 

! 

STORAGE-CAPABILITY  [+] 

0..x" 

A  CAPABILITY,  requred  for 
planning,  of  those  FACILITY'S  or 
MATERIELs  or 
EQUIPMENT-TYPEs,  or 
FACILITY-TYPEs  that  are 
deemed  as  having  the  abftty  to 
hold  a  specific 
MATERIEL-TYPE. 


Figure  32.  materiel-type  construct  found  in  the  C2IEDM. 
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<xsl:template  name="EquipmentHoldings"> 

<xsl:for-each  select=".. /HOLDING"> 

<xsl: variable  name="holdingObjectTypelD"  select="object-type-id"/> 
<xsl:for-each  select="../../OBJECT-TYPE"> 

<xsl: variable  name="objectTypelD"  select="object-type-id"/> 

<xsl:if  test="$objectTypelD  =  $holdingObjectTypelD"> 

<xsl:if  test="object-type-category-code  /*  [local-name()  =  'MA']"> 
<xsl:apply-templates  select="MATERIEL-TYPE"/> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:for-each> 

</xsl:template> 


Figure  33.  EquipmentHoldings  template  used  to  determine  object-type  in 
the  equipment  extraction  portion  of  the  C2IEDM  to  UOB  XSLT. 


<xsl:template  match="MATERIEL-TYPE"> 

<xsl:if  test="materiel-type-category-code  /*  [local-name()  =  'EQ']"> 

<xsl:element  name="Equipment"> 

<xsl:attribute  name="code">  <xsl:value-of  select-'. ./object-type-name”/>  <xsl:attribute/> 
<xsl:apply-templates  select  ="./EQUIPMENT-TYPE"/> 

<xsl:element  name="Required"> 

<xsl:value-of  select="../HOLDING/holding-operational-quantity"/> 

</xsl:element> 

<xsl:element  name="Authorized"> 

<xsl:value-of  select="../HOLDING/holding-total-quantity"/> 

</xsl:element> 

</xsl:element> 

</xsl:if> 

</xsl:template> 


Figure  34.  materiel-type  template  used  to  test  the  classification  of 
equipment  in  the  C2IEDM  to  UOB  XSLT. 
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The  template  in  Figure  34  begins  by  conducting  a  test  to  see  if  the  type  of 
materiel  identified  in  the  model  is  of  equipment  type.  It  does  this  by  checking  to 
see  if  the  materiel-type-category-code  is  EQ .  Then  it  begins  to  output 
part  of  the  result  structure  necessary  for  the  output  document.  It  then  calls  the 
template  that  will  identify  and  extract  the  type  of  unit  equipment  it  has  found. 
Figure  35  shows  the  equipment-type  construct  located  in  the  C2IEDM  and 
Figure  36  shows  a  portion  of  the  XSLT  template  created  to  determine  the 
equipment’s  equipment  type.  This  template  uses  a  choose  construct  with  a 
series  of  when  tests  to  determine  the  type  of  equipment  it  has  identified.  The 
result  of  this  template  is  that  the  type  of  equipment  is  identified  and  the  parser 
extracts  the  description  of  the  piece  of  equipment  from  its  category  code.  The 
parser  then  returns  to  the  template  seen  in  Figure  34  and  extracts  the  quantities 
on  hand  and  authorized  for  the  item  of  equipment. 
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— |  equipment-type-id~| 

The  materieS-type^d  of  a 
specific  EQUIPMENT-TYPE 
(a  rote  name  for 
object-cype-id). 


— equipment-type-category  -code  [+] 

The  specific  value  that  represents  the  dass 
of  EQUIPMENT-TYPE. 


equipment-type-loaded-weight-. 


The  noo-monecary  numeric  value  that 
represe-ts  the  weight  of  a  specific 
EQUIPMENT-TYPE  tedudteg  the  normal 
maximum  payload,  crew,  and 
persona  l/orga  n.saton  equ.pment  as  well  as  the 
basx  issue  items.  The  unit  is  kilogram. 


equipment-type-unloaded-weig... 


The  noo-monetary  numeric  value  that 
represents  t"e  weght  of  a  spedfic 
EQUIPMENT-TYPE  including  on-ecuipmenc 
matenel  that  is  an  integral  part  of  the 
equipment  when  ssued.  The  unit  is  kilogram. 


— |  AIRCRAFT-TYPE  [+] 

An  EQUIPMENT-TYPE  that 
is  desgned  to  fty. 


— |  ELECTROHIC-EQUIPMENT-TYPE  [+) 

An  EQUIPMENT-TYPE  that  s  desgned  » 

use  electronic  processing  to  reafee  its 
primary'  function. 


— |  EHGIHEERIIIG-EQUIPMEHT-TYPE  ]+| 

An  EQUIPMENT-TYPE  that  is  desgned  to 
accomplish  engineering  functions. 


EQUIPMENT-TYPE 


A  MATERIEL-TYPE  that  s 
not  intended  for 
consumption. 


L  LAND-VVEAPON-TYPE  |+) 

An  EQUIPMENT-TYPE  that 
s  desgned  for  the  delivery'  of 
fires  whie  operating  on  land 
surface. 


— |  miscellaneous-equipment-tyT^) 

An  EQUIPMENT-TYPE  whose  desgned 
function  does  rot  fit  in  any  other  defined 
category'. 


— |  NBC -EQUIPMENT -TYPE  [+] 

An  EQUIPMENT-TYPE  that  s 
desgned  for  speoaised  rotes  in 
detecting,  decontaminating  or 
reconnoitring  NBC  agents. 


— |  RAILCAR-TYPE  [+] 

An  EQUIPMENT-TYPE  that 
is  desgned  to  operate  on  rail 
tracks. 


UNIT -TYPE  [j] 

y.v.v.v.-.vcj.-; 

0..x 

A 

MILIT  ARY-ORGANISATIO 
N-TYPE  whose  structure  s 
prescribed  by  competent 
authority. 


— |  VEHICLE-TYPE  \+\ 

An  EQUIPMENT-TYPE  that 
is  desgned  to  operate  on 
land  routes  (ocher  than  ral) 
with  a  primary  rote  of 
transporting  personnel, 
equipment  or  supples. 

— |  VESSEL-TYPE  [+] 

An  EQUIPMENT-TYPE  that 
is  desgned  to  operate  on  or 
under  the  water  surface. 


Figure  35.  equipment-type  construct  found  in  C2IEDM. 
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<xsl:template  match  =  " EQUIPM ENT-TYPE" > 

<xsl: element  name="Description"> 

<xsl:choose> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'AIRCFT']"> 
<xsl:value-of  select="AIRCRAFT-TYPE/aircraft-type-subcategory-code/*/@value"  /> 
</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'ELCTRN']"> 
<xsl:value-of  select="ELECTRONIC-EQUIPMENT-TYPE/electronic-equipment-type- 
subcategory-code/*/@value"  /> 

</xsl:when> 

<xsl:when  test="equipment-type-category-code /*  [local-name()  =  'ENGEQ']"> 
<xsl:value-of  select="ENGINEERING-EQUIPMENT-TYPE/engineering-equipment-type- 
category-code/*/@value"  /> 

</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'LNDWEP']"> 
<xsl:value-of  select="LAND-WEAPON-TYPE/land-weapon-type-category- 
code/*/@value"/> 

</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'MISCEQ']"> 
<xsl:value-of  select="MISCELLANEOUS-EQUIPMENT-TYPE/miscellaneous-equipment- 
type-category-code/*/@value"  /> 

</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'NBCEQ']"> 
<xsl:value-of  select="NBC-EQUIPMENT-TYPE/nbc-equipment-type-category- 
code/*/@value"/> 

</xsl:when> 

<xsl otherwise  /> 

</xsl:choose> 

</xsl:element> 

</xsl:template> 


Figure  36.  Partial  EquipmentType  template  used  to  extract  equipment 
descriptions  from  the  equipment-type  construct  found  in  C2IEDM. 


Figures  37  and  38  show  the  equipment-type-category-code  and 
land-weapon-type-category-code  constructs  from  the  C2IEDM.  Once  the 
parser  has  gotten  down  to  the  command  xsl :  value-of  seen  in  Figure  36,  it 
extracts  the  content  of  the  attribute  value  which  contains  a  brief  description  of 
the  piece  of  equipment.  This  data  is  necessary  input  for  the  description 
element  found  in  the  UOB  schema  compliant  result  document. 
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Figure  37.  Equipment-type-category-code  construct  found  in  the 

C2IEDM. 
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Figure  38.  Land-weapon-type-category-code  construct  found  in  the 

C2IEDM. 
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6. 


Unit  Present  Location 


To  obtain  the  unit’s  present  location  from  the  C2IEDM  more  than  the 
object-item-id  and  obj ect-type-id  are  required.  The  structure  within 
the  C2IEDM  that  contains  the  longitude  and  latitude  for  the  unit  object  is  not 
concerned  with  the  object-item  or  object-type-id.  It  is  concerned  with  a 
location-id.  Figure  39  shows  the  template  that  is  executed  to  extract  the 
present  location  for  the  unit. 


<xsl:template  name="RelativellnitLocation"> 

<xsl  :param  name="UnitObjectltem  I  D"/> 

<xsl:param  name="UnitObjectltemLocationlD"/> 

<xsl:element  name="Present"> 

<xsl:element  name="Name">This  is  the  Name  of  the  Current  Geographical  Location  of  this  unit</xsl:element> 
<xsl:for-each  select="../../../OBJECT-ITEM-LOCATION"> 

<xsl:variable  name-'ObjectltemLocationObjectltemlD"  select="object-item-id'V> 

<xsl:variable  name="ObjectltemLocationLocationlD"  select="location-id"/> 

<xsl:for-each  select="../../LOCATION"> 

<xsl:variable  name-'LocationID"  select="location-id"/> 

<xsl:if  test="$UnitObjectltemlD  =  $ObjectltemLocationObjectltemlD"> 

<xsl:if  test="$UnitObjectltemLocationlD  =  $LocationlD"> 

<xsl:element  name="Latitude"> 

<xsl:value-of  select="POINT/ABSOLUTE-POINT/absolute-point-latitude-coordinate"/> 
</xsl:element> 

<xsl:element  name="Longitude"> 

<xsl:value-of  select="POINTVABSOLUTE-POINT/absolute-point-longitude-coordinate"/> 
</xsl:element> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 


Figure  39.  Relative  Unit  Location  template  to  extract  latitude  and  longitude  for 

the  unit  current  location. 


When  the  template  is  called  two  parameters  are  passed  to  it.  The  first  is 

the  UnitObjectltemlD  which  contains  the  original  object-item-id 

extracted  for  the  unit  in  the  first  template  call.  The  second  parameter, 
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UnitOb j ect I temLocationlD  is  the  location-id  obtained  from  the 
object-item-location  element  of  the  BIXS.  This  parameter  is  carefully 
selected  by  backing  out  from  the  context  of  the  unit-formal-abbreviated- 
name  to  the  object -item-location  structure  and  then  down  the  tree  to  the 
location-id.  The  first  iteration  inside  the  template  searches  through  all  of  the 
object-item-ids  and  location-ids  found  within  the  OBJECT-ITEM- 
LOCATION  structure  in  the  model  and  assigns  them  to  local  variables.  A  second 
iteration  is  then  used  to  search  through  all  of  the  location-ids  in  the  model 
found  in  the  location  structure  and  places  them  in  a  local  variable  as  well. 

From  there  the  object-item-ids  and  location-ids  are  checked  against 
the  ones  passed  into  the  template.  The  first  test  conducted  in  the  template 
checks  to  see  if  the  ob  j  ect-item-id  that  was  passed  to  the  template  matches 
the  one  extracted  from  the  object- item-location  structure. 

The  second  test  conducted  in  the  template  checks  to  see  if  the 
location-id  extracted  from  the  location  element  of  the  model  matches  the 
one  extracted  from  the  object-item-location  element.  This  test  ensures 
that  the  location-ids  match  and  allows  the  extraction  of  the  latitude  and 
longitude  from  the  model  to  commence.  The  values  of  latitude  and  longitude  are 
located  within  the  point  structure  of  the  BIXS.  Before  the  extraction  of  the 
latitude  and  longitude,  the  parser’s  context  is  in  the  location  structure.  The 
point  element  is  a  child  of  location  so  all  that  is  required  to  extract  the 
latitude  and  longitude  is  to  direct  the  parser  to  the  location  of  the  values  using  the 
XPath  expression  seen  within  the  template. 

7.  Unit  Type  Category  Code 

One  piece  of  information  that  is  important  to  have  is  the  military  unit’s 
type.  The  focus  here  is  on  a  U.S.  Army  Cavalry  Troop  whose  primary  mission  is 
reconnaissance  and  combat  operations.  Units  in  the  U.S  Army  are  grouped  into 
one  of  three  class  types,  combat,  combat  service  support  and  combat  support. 
Armored  Cavalry  troops,  like  A  Troop  1/3  ACR  are  categorized  as  combat  units. 

Examples  of  combat  service  support  and  combat  support  unit  types  are 
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Transportation  and  Military  Intelligence  units  respectively.  Figure  40  shows  the 
UnitTypeCategoryCode  template  from  the  XSLT  stylesheet  used  to  extract  what 
the  UOB  denotes  as  the  DescriptionCode  for  the  unit.  Only  three  codes  are 
necessary  for  the  classification  of  the  unit  type  here:  AAC  for  combat,  AAS  for 
combat  support  and  AAV  for  combat  service  support.  Additional  codes  are 
available  within  the  UOB  which  satisfy  the  other  services  and  countries’ 
requirements  to  classify  their  units. 

<xsl:template  name  =”UnitTypeCategoryCode”> 

<xsl:param  name="OTypelD"/> 

<xsl:element  name="DescriptionCode"> 

<xsl:for-each  select-'. /OB JECT-TYPE"> 

<xsl:variable  name="LocalObjectTypelD"  select="object-type-id"/> 

<xsl:if  test="$OTypelD  =  $LocalObjectTypelD"> 

<xsl:if  test="object-type-category-code/*  [local-name()  =  '0R']"> 

<xsl:if  test="ORGANISATION-TYPE/organisation-type-category-code/*  [local-name()  =  'GVTORG’]"> 
<xsl:if  test-'ORGANISATION-TYPE/GOVERNMENT-ORGANISATION-TYPE/govemment- 
organisation-type-category-code/*  [local-name()  =  'MILORG']"> 

<xsl:if  test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION-TYPE/MILITARY- 
ORGANISATION-TYPE/military-organisation-type-category-code/*  [local-name()  =  'UNIT']”> 

<xsl:choose> 

<xsl:when  test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category-code/*  [local-name()  = 
'COMBAT']">AAC</xsl:when> 

<xsl:when  test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category-code/*  [local-name()  = 
’COMSER’]">AAV</xsl:when> 

<xsl:when  test-'ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category-code/*  [local-name()  = 
'COMSPT']">AAS</xsl:when> 

<xsl:otherwise>U</xsl:otherwise> 

</xsl:choose> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 


Figure  40.  UnitTypeCategoryCode  template  used  to  extract  data  from  the 

unit-type-category-code  of  the  BIXS. 
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For  this  implementation  to  succeed,  one  of  many  tree  structures  within  the 
C2IEDM  must  be  traversed  in  order.  The  method  to  do  this  within  the  XSLT  is 
through  a  series  of  if  tests.  The  tests  conducted  at  each  level  of  the  tree  check 
node  contents  and  codes  to  ensure  that  they  meet  the  specified  requirements. 
Step  one  in  the  process  is  to  direct  the  parser  to  again  iterate  through  all  of  the 
object-types  in  the  model  and  select  their  ob j  ect-type-ids.  This  is  done 
so  that  the  extracted  object-type-id  may  be  compared  against  the  object- 
type-id  passed  in  during  the  template  call.  Matching  these  ids  indicates  that 
we  are  dealing  with  the  correct  unit. 

Next  the  object-type-category-code  for  the  OBJECT-TYPE  selected 
is  checked  to  see  if  it  is  of  type  organization-type.  This  test  is  required 
because  object-types  may  have  several  different  values  within  the  model  and 
only  the  'OR'  value  is  needed  here  indicating  that  the  object  is  an  organization. 
Next  the  parser  checks  to  see  if  the  organisation-type-category-code  of 
that  organisation-type  is  gvtorg.  The  gvtorg  code  indicates  a 
government-organisation-type  and  is  the  one  we  are  concerned  with. 
Figure  41  shows  the  organisation-type  structure  of  the  C2IEDM.  Figure  42 
depicts  the  organisation-type-category-code. 
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ORGANISATIOIJ-TYPE 


An  OBJECT-TYPE  that 
represe"ts  administrative  or 
functional  structures. 


organisation-type-id 


The  object-type-id  of  a 
specific 

ORGANISATION-TYPE  (a 
rote  name  far  otiject-typend). 


{ organisation-type-category -code  [+] 


The  value  that  reorese-ts  the  class  of 
ORGANISATION-TYPE. 


^organisation-type-command-fu...  |+| 


The  specie  value  fat  ce-cces  w-erer  an 
ORGANISATION-TYPE  has  a  command 
function. 

““““““““““““““““““““““““““““““““ ~  *1 

•G  organisation-type-command-an...  [+] 

v  -  -  mm  m  mmmmm  -  mmmmmmmm . . al 

The  specific  value  that  demotes  tne  command 
and  control  classification  of  an 
ORGANISATION-TYPE. 


organisation-type-description-t... 


The  u formatted  caract©"  sy:"g  that 
cnaracterses  the  specific 
ORGANISATION-TYPE. 


CIVILIAN-POST-TYPE 


1 


An  ORGANISATION-TYPE 
with  a  set  of  duties  that  are 
intended  to  tie  falfited  by  one 
person  in  pnvate  seexx  and 
notwr:' 


An  ORGANISATION-TYPE  that  Is 
noo-farmal  in  nature  and  casses 
together  its  members  due  to  mutual  or 
common  circumstances. 


PRIVATE-SECTOR-ORGANISATIO... 


5 


An  ORGANISATION-TYPE  that  is  a 
non-government  organisation  and  is  constituted 
for  business,  commerce,  manufacturing,  trade, 
refeef  or  philanthropy. 


Figure  41 .  organisation-type  structure  found  in  the  BIXS. 
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Figure  42.  The  expanded  organization-type-category-code  found 
within  the  organisation-type  structure  from  the  BIXS. 


Next  the  parser  proceeds  one  level  deeper  into  the  source  tree  structure 
to  determine  if  the  GOVERNMENT -ORGANISATION- TYPE  '  s  government- 
organisation-type-category-code  is  milorg.  milorg  is  the  category 
code  indicating  an  organization  is  a  military  organization.  Figure  43  depicts  part 
of  the  tree  structure  containing  the  government-organisation-type- 
category-code  structure  found  within  the  BIXS  schema  that  is  traversed  to 
obtain  this  information.  Now  the  parser  checks  the  structure  seen  in  Figure  44  to 
see  if  the  MILITARY-ORGANISATION-TYPE  has  a  military- 
organization-type-category-code  of  UNIT.  This  indicates  that  the  node 
being  examined  is  a  unit  and  that  the  only  further  processing  required  is  to 
extract  the  information  referencing  what  type  of  unit  we  are  examining.  The 
extraction  of  the  code  labeling  the  unit  is  completed  using  a  choice  statement 
that  is  similar  to  a  switch  statement  in  other  coding  languages.  The  choice 
statement  may  be  reviewed  in  Figure  40.  Figure  45  shows  the  partial  tree 

structure  leading  to  the  unit-type  node  of  the  BIXS  schema. 
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C2IEDM. 
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military-orgainisation-type  structure  within  the  C2IEDM. 


Figure  46  shows  the  expanded  unit-type  structure  found  within  the 
C2IEDM.  This  construct  in  the  source  document  is  the  final  focal  point  for  both 
template  extractions  of  the  DescriptionCode  being  attempted  here  and  the 
LevelCode  discussed  in  the  next  section.  These  two  pieces  of  information  are 
the  last  two  pieces  extracted  to  build  our  (JOB  compliant  unit  source  document. 
Figure  47  shows  the  expanded  view  of  the  unit-type-category-code  with 
the  three  unit  types  found  within  the  unit-type  node.  A  great  deal  of 
information  is  contained  within  the  unit-type  structure  that  is  not  examined 
within  the  current  work.  Extensions  of  this  research  include  increasing  the 
robustness  of  the  unit  document  to  include  other  service  requirements,  some  of 
which  may  be  satisfied  through  data  extraction  from  the  unit-type  element. 
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The  orgarysaton-typend  of  a  specfc 
MIUT ARV-ORG ANISATION-TYPE  chat  is 
supported  by  a  specific  UNIT-TYPE  (a  roie 
name  for  object-type-id). 

Figure  46.  unit-type  structure  found  in  the  BIXS  containing  both  the  unit- 

type-category-code  and  the  unit-type-size-code. 
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8.  Unit  Type  Size  Code 

The  last  piece  of  the  unit  document  deals  with  the  echelon  of  the  unit.  The 
term  echelon  is  synonymous  in  this  instance  with  size.  Army  units  range  in  size 
from  sections  to  armies.  The  size  of  the  unit  in  this  work  is  a  Troop.  Troops  in 
the  U.S.  Army  are  special  organizations  found  only  in  Cavalry  units.  Outside  of 
Cavalry  units,  this  size  of  unit  is  called  a  Company.  Companies  and  Troops 
contain  the  same  level  of  commander  although  their  organizations  differ  greatly. 
Generally,  the  standard  size  term  used  when  discussing  a  unit  of  this  level  or 
echelon,  is  Company.  This  is  noticeable  within  the  C2IEDM  as  there  is  not  a 
Troop  echelon  within  the  model.  (JOB  on  the  other  hand  does  include  Troop  as 
one  of  its  standard  unit  echelons.  The  two  closest  matches  to  be  found  within 
C2IEDM  are  company  and  company-team.  For  some,  the  company-team  may 
be  a  more  accurate  description  of  a  Cavalry  Troop.  This  is  due  to  the  makeup  of 
a  Troop.  A  Cavalry  Troop  within  a  heavy  Cavalry  Regiment  will  have  a  mix  of 
vehicles  including  tanks,  armored  personnel  carriers  (APC),  cavalry  fighting 

vehicles  (CFV),  armored  maintenance  recovery  assets  and  wheeled  vehicles 
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ranging  in  size  and  hauling  capability  from  V2  to  5  tons.  While  a  company-team 
does  not  have  the  expanse  of  assets  that  a  Troop  has,  it  does  contain  a  mix  of 
tanks,  infantry  fighting  vehicles  (IFV),  APCs,  wheeled  vehicles  and  may  have 
attached  to  it  additional  assets  that  it  would  not  normally  have.  This  is  generally 
done  if  the  unit  is  being  assigned  a  mission  that  it  was  not  originally  designed  for 
like  a  screening  mission.  Screen,  Guard  and  Cover  missions  are  standard  for 
the  Cavalry  but  not  necessarily  for  Armored  or  Mechanized  Brigades.  Figure  48 
shows  the  partial  template  that  extracts  the  unit-type-size-code  from  the 
C2IEDM.  The  full  template  may  be  viewed  in  Appendix  D. 

<xsl:template  name="UnitTypeSizeCode"> 

<xsl:param  name="ObjTyplD"/> 

<xsl:element  name="LevelCode"> 

<xsl :for-each  select="../. ./. ./. ./OB JECT-TYPE"> 

<xsl:variable  name-'LocalObjTypID”  select-'object-type-id"/> 

<xsl:if  test="$ObjTyplD  =  $LocalObjTyplD"> 

<xsl:if  test="object-type-category-code/*  [local-name()  =  'OR']"> 

<xsl:if  test="ORGANISATION-TYPE/organisation-type-category-code/*  [local-name()  =  'GVTORG']"> 
<xsl:if  test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION-TYPE/government- 
organisation-type-category-code/*  [local-name()  =  'MILORG']"> 

<xsl :  if  test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION-TYPE/MILITARY- 
ORGANISATION-TYPE/military-organisation-type-category-code/*  [local-name()  =  'UNIT']"> 

<xsl:choose> 

<xsl:when  test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/*  [local-name()  =  ,BDE,]">BDE</xsl:when> 
<xsl:when  test-'ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/*  [local-name()  =  'CBTTM']">CO</xsl:when> 
<xsl:when  test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/*  [local-name()  =  'COY']">CO</xsl:when> 
<xsl:otherwise>U</xsl:otherwise> 

</xsl:choose> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 


Figure  48.  Partial  template  used  to  extract  the  unit  LevelCode  necessary  for 

the  UOB  result  document. 
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It  so  happens  that  this  template  is  identical  to  the  one  used  to  extract  the 
unit  DescriptionCode  information  in  the  previous  section.  The  only  difference 
in  this  template  is  in  the  choose  construct.  For  this  implementation  the 
necessary  information  is  located  in  the  unit-type-size-code.  Figure  49 
shows  the  partial  tree  structure  encompassing  the  unit-type-size-code 
structure.  Once  the  proper  match  is  made  inside  the  choose  statement  the 
information  is  extracted  and  the  result  document  is  complete. 


- -j? MILITARY-ORGANI SATION-TYPE  EH— ~ )=[- 

A 

GOVERNMENT-ORGANISATION-TYPE 
that  is  officially  sanctioned  and  is  trained 
and  eouipped  to  e>ert  force. 


Figure  49.  Partial  unit-type-size-code  structure  found  within  the  C2IEDM 
used  to  obtain  the  unit  LevelCode  for  the  (JOB  compliant  result  document. 

D.  SUMMARY 

This  chapter  has  discussed  the  importance  of  XML  and  has  provided  an 

exemplar  using  XML  and  XSLT  to  transform  data  about  a  military  unit  from  a 

form  understood  by  a  command  and  control  system  into  a  form  usable  by  a 

simulation.  The  exemplar  shows  the  enabling  power  of  XML  and  XSLT  as 

methods  of  data  representation  that  facilitate  interoperability.  The  work 

completed  here  provides  a  reason  why  a  solid  understanding  of  XSLT  by 
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--  UNIT-TYPE  Q- 


-& 


0..OD 

A 

MIUTARY-ORGANISATIO 
N-TYPE  whose  structure  is 
prescribed  by  competent 
authority. 


k  unit-type-size-code 

The  specific  value  that 
represents  re  relative  sae  of 
the  commonly  accepted 
configuration  of  m#cary 
formations. 


|  COY 

Base  administrative  and 
tactical  unit  in  most  arms  and 
services  of  the  Army.  A 
company  is  on  a  command 
level  below  a  battalion  and 
above  a  platoon. 


COYG 


An  operational  grouping 
which  is  based  on  an 
nfantry  company  and  which 
has  events  of  other 
supporting  arms  and  services 
allocated  according  to  need. 


CORPS 


A  formation  larger  than  a 
division  but  smaler  than  ar 
army  or  army  group.  It 
usuafty  consists  to  two  or 
more  divisions  together  wit 
supporting  arms  and 
services. 


DIV 


A  tactical  urvt/formation  that 
s  a  major  administrative  and 
tactical  urvt/formation  that 
combnes  m  eelfthe 
necessary  arms  and  services 
reoured  for  susamed 
combat,  larger  than  a 
reg:-*nen».brgade  and  smafler 
than  a  corps. 


An  organisation  of  shps. 
srerafe  Marne  forces,  and 
shore-based  feet  activities 


simulation  developers  and  its  incorporation  into  the  process  of  data  interchange 
is  vital  to  the  extensibility  of  models  and  simulations.  This  is  a  key  point. 

Since  XML  is  extensible  and  platform  independent  its  use  has  fostered 
interoperability  without  the  post  development  requirement  for  special  wrapper  or 
interface.  While  it  is  arguable  that  if  all  simulations  and  C2  systems  were  written 
in  the  same  computer  language  this  would  also  be  possible,  it  is  not  true  that  the 
extensibility  and  ease  of  use  would  be  comparable.  The  focus  here  is  on  the 
data  and  its  representation  not  the  code  used  to  run  either  application.  The 
C2IEDM  representation  used  in  this  example  was  vital  to  the  success  of  the 
transformation  due  to  its  representation  using  XML.  Without  this  representation 
of  the  C2IEDM  a  more  complex  procedure  would  have  been  necessary  for  the 
extraction  of  the  data  contained  within  a  database.  The  bottom  line  is  “the  role  of 
XML  Transformation  for  interoperability  cannot  be  understated,  since  it  allows 
integration  of  existing  databases  and  systems,  and  promotes  application 
independent  information  management  at  the  data  level”  (Neushul,  2003). 

On  the  other  hand,  human  judgment  was  applied  throughout  in  order  to 
make  the  data  associations  summarized  in  Table  1 .  The  full  power  of  automated 
interoperability  across  systems  will  only  be  realized  when  software  is  able  to 
understand  the  common  concepts  used  by  different  data  models  and  XML 
representations.  This  is  the  hope  of  emerging  Semantic  Web  research  and 
applications  (Blais,  2004a). 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

New  uses  are  being  created  on  a  daily  basis  for  our  legacy  models  and 
simulations  in  the  fight  on  terrorism.  New  systems  are  needed.  We  no  longer 
have  a  well  defined  threat.  Some  say  that  today’s  threat  is  pan-national  and 
asymmetric.  Few  disagree. 

The  importance  of  knowledgability  incorporating  XML  in  the  analysis, 
design  and  development  phases  of  current  and  future  systems  cannot  be 
overstated.  The  current  lack  of  interoperability  between  our  command  and 
control  systems,  models  and  simulations  is  unacceptable.  Precious  resources, 
(both  money  and  manpower)  are  being  spent  to  develop  useful  tools  for  both 
military  analysts  and  training  professionals,  but  very  little  money  or  time  is  being 
spent  developing  the  interfaces  or  interoperability  between  these  systems  until 
too  late  in  the  development  process.  It  is  no  longer  enough  to  have  great 
software  tools.  They  must  also  interface  with  one  another  and  be  modular 
enough  to  support  common  data  models  and  exchange  documents. 

The  C2IEDM  model  incorporates  the  ontology  of  the  military  community,  is 
extensible,  and  has  been  shown  to  be  interoperable  and  transformable  for  use 
with  a  simulation  package.  Joint  Forces  Command  (JFCOM)  is  incorporating  the 
C2IEDM  in  their  new  command  and  control  structure.  The  simulation  community 
of  interest  (COI)  has  recognized  that  they  need  to  begin  focusing  on 
interoperability  between  themselves  and  the  Command  and  Control  COI.  Figure 
50  (Chaum  and  others,  2004)  depicts  DMSO’s  vision  for  future  interoperability 
incorporating  many  of  the  concepts  addressed  in  this  thesis.  The  use  of  XML 
based  technologies  and  architectures  such  as  XMSF  enhance  the  possibilities  for 
interoperability,  interchange  and  visualization. 
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C4I  /  Simulation  Interoperability 

-  A  logical  view  of  C2IEDM  as  an  objective  interlingua  - 

Strategic,  Operational 
&  Tactical  Systems 


Operational  and  Tactical 
Chaum/Dobey/Swenson  1/30/04  Information  Exchanges 


C'4I  Injects  from  Simulations 

Real-world  Operational  and  Tactical 
Information  to  Simulations 
(e.g.,  Tasking  for  simulated  forces. 
Real-world  tracks,  stams,  etc.) 


Figure  50.  DMSO’s  vision  of  future  interoperability  using  C2IEDM  (From 

Chaum  and  others,  2004) 


This  research  has  provided  the  reader  with  several  examples  of  how  the 
DoD  and  academia  are  working  towards  interoperable  solutions  that  fit  within 
today’s  military  concept  of  operations.  To  say  that  this  work  has  uncovered  the 
“Holy  Grail”  to  fix  all  of  the  interoperability  difficulties  within  the  DoD  would  be  a 
bit  naive.  This  examination  of  using  the  C2IEDM  as  the  data  interchange 
method  to  interface  with  the  FAST  Toolbox  is  only  the  tip  of  the  iceberg  in  terms 
of  C2/simulation  interoperability.  The  FAST  Toolbox  is  a  relatively  new  set  of 
tools  that  have  been  built  under  the  purview  of  interoperability.  Other  modeling 
and  simulation  tools  such  as  Vector  in  Commander  (VIC)  and  Janus  are  not  so 
new  and  were  designed  and  built  during  a  period  when  interoperability  with  C2 
systems  was  not  an  issue.  Now  we  are  looking  for  ways  to  re-engineer  these 
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tools  to  enhance  them  for  today’s  warfighting  missions  and  leverage  their  power 
within  other  applications. 

The  C2IEDM  is  a  complex  and  powerful  data  exchange  model.  Its  ability 
to  bend  to  the  needs  of  the  user  is  critical  in  today’s  unpredictable  environment. 

It  has  been  tested  on  several  occasions  to  show  that  through  its  use 
interoperability  amongst  national  C2  systems  can  be  achieved  and  that  a 
common  operating  picture  can  be  shared.  This  work  has  shown  that  using  the 
C2IEDM  within  the  Simulation  COI,  interoperability  between  a  simulation 
package  and  C2  system  using  the  C2IEDM  as  the  data  interchange  mechanism 
may  also  be  achieved.  This  is  a  critical  point.  While  further  enhancements  and 
development  are  necessary  for  the  C2IEDM  to  completely  satisfy  the  needs  of 
many  simulation  and  C2  applications,  it  can  be  used  now  for  data  interchange 
within  some  applications.  Coupling  XML  with  XSLT  provides  a  sound  method  for 
describing  and  transforming  data  between  applications  as  an  after  thought  but 
careful  design  including  the  use  of  these  technologies  wrapped  in  an  architecture 
like  XMSF  will  provide  extensible,  open  and  interchangeable  solution  to  an  old 
and  continuing  problem  within  the  C2  and  simulation  COIs. 

Unfortunately  there  is  never  enough  time  to  accomplish  everything.  The 
following  lists  several  projects  that  can  extend  the  work  done  in  this  research  to 
make  it  more  robust. 

B.  RECOMMENDATIONS  FOR  FUTURE  WORK 

Several  items  are  listed  in  this  section  as  future  work.  The  first 
recommendation  is  to  complete  the  work  started  here  by  fleshing  out  this  XSLT 
so  that  any  military  unit  described  in  the  C2IEDM  can  be  extracted  and  used 
within  the  FAST  Toolbox.  The  focus  here  was  on  a  single  U.S.  Army  ground 
Cavalry  unit  and  its  main  equipment.  There  were  no  aircraft,  watercraft  or 
railroad  equipment  associated  with  the  unit  selected  so  the  XSLT  is  not  designed 
to  handle  units  that  have  those  types  of  equipment.  This  is  the  next  logical  step 
in  extending  and  completing  the  current  research. 
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In  order  to  accomplish  this  however,  a  complete  source  file(instance 
document)  is  necessary.  One  of  the  difficulties  encountered  during  this  work  was 
the  lack  of  a  complete  source  file  based  on  the  BIXS.  In  order  to  test  the  current 
XSLT  process,  a  source  file  was  auto  generated  from  the  BIXS  by  XMLSpy. 
Values  were  changed  in  that  source  file  where  the  author  believed  they 
belonged.  This  resulted  in  a  partial  file  that  has  been  subsequently  built  upon 
throughout  the  development  of  the  XSLT.  In  order  to  properly  test  and  evaluate 
this  XSLT  file,  software  should  be  written  to  extract  the  data  values  from  the  IDA 
C2IEDM  database  and  create  a  source  file  based  on  the  BIXS.  With  this,  full  and 
rigorous  testing  of  the  work  created  here  may  be  completed. 

The  next  proposal  is  the  revision  of  the  BIXS  created  by  Capt.  James 
Neushul  (Neushul,  2003).  Neushul’s  BIXS  is  a  very  complex  and  lengthy 
document.  It  is  an  XML  document  with  a  very  large  hierarchical  structure.  The 
C2IEDM  itself  causes  this  problem  with  its  many  to  many  relationships.  When 
exposed  using  XML,  data  that  is  normally  contained  within  a  database  in  tables  is 
now  replicated  many  times  in  many  different  places  within  the  structure  of  the 
model.  Aside  from  this,  the  BIXS  is  a  powerful  piece  of  work.  Because  the  BIXS 
version  of  the  C2IEDM’s  data  is  completely  exposed,  XSLT  may  be  brought  to 
bear  on  it  and  there  is  no  reason,  other  than  time,  that  it  cannot  be  fully 
manipulated  to  suit  the  needs  of  users.  A  similar  rendition  of  the  model  using  a 
database  to  hold  data  values  would  require  additional  software  to  traverse  and 
manipulate  tables  in  the  databases,  something  humans  alone  cannot  do.  An 
effort  to  increase  the  usefulness  of  the  BIXS  has  been  to  apply  Java  Architecture 
for  Data  Binding  (JAXB)  to  it.  This  effort  has  had  limited  success.  This  is  mainly 
due  to  the  enormous  size  of  the  document.  One  recommended  step  to  revising 
the  BIXS  is  to  name  the  complex  types  that  are  found  within  the  model.  This  will 
help  to  reduce  the  size  of  many  of  the  methods  generated  by  applying  JAXB. 

One  logical  follow-on  project  of  this  work  is  the  creation  of  additional  XSLT 

to  transform  unit  data  from  the  UOB  version  7.7  schema  structure  to  the  BIXS 

(C2IEDM)  structure.  This  may  be  the  next  exemplar  showing  the  extensibility  of 

the  C2IEDM  and  its  value  in  the  C2/simulation  communication  process.  Table  1 
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of  this  work  provides  the  beginnings  for  a  round  trip  showing  information  transfer 
from  C2IEDM  to  UOB  and  back.  Along  with  this,  the  implementation  of  both 
XSLTs  in  the  FAST  Toolbox  would  be  the  final  exemplar  to  prove  that  the 
C2IEDM  is  the  logical  choice  for  connecting  simulations  and  C2  systems. 

Another  avenue  for  research  is  the  incorporation  of  the  BIXS  into  work 
involving  tactical  chat  and  tactical  messaging.  Research  and  development  is 
ongoing  involving  the  use  of  C2IEDM  in  the  area  of  mission  planning  and 
visualization. 

Further  research  is  needed  into  the  MDA  concept  summarized  here. 

Many  questions  raised  during  the  research  into  this  architecture  need  to  be 
answered  before  the  MDA  can  be  fully  understood  and  utilized  outside  of  the 
OMG.  Time  will  tell  if  MDA  will  falter  or  flourish  as  a  proven  architecture  for 
software  development. 

A  chapter  of  this  work  that  was  not  realized  was  the  prospect  of 
developing  a  web  service  to  fully  expose  the  UOB  toolset.  From  a  user’s 
perspective,  the  UOB  is  one  stop  shopping  for  data  related  to  military  units.  As  it 
stands,  using  UOB  requires  special  permissions  and  a  server  and  client.  A  more 
robust  UOB  toolset  could  use  the  power  of  the  web  to  make  unit  data  available 
for  any  level  commander  who  could  use  the  data  along  with  other  applications 
such  as  X3D,  to  create  realistic  training  scenarios  at  the  small  unit  level.  These 
types  of  applications  would  provide  a  powerful  training  environment  for  units  with 
small  footprints  and  smaller  budgets. 

Lastly,  a  full  comparison  of  the  two  versions  of  C2IEDM  mentioned  and 
used  here  is  necessary.  Many  developers  and  users  alike  are  unclear  as  to 
which  representation  of  the  C2IEDM  will  work  best  for  them.  While  the  several 
representations  developed  may  subscribe  to  the  intent  of  the  C2IEDM  model 
their  presentation  methods  are  in  some  cases  much  different.  The  BIXS  and  the 
IDA  C2IEDM  schemas  provide  two  good  examples  to  compare  and  contrast  to 
address  what  aspects  of  each  are  good  and  bad.  One  is  database  centric  while 
the  other  is  very  much  document  centric.  These  constructive  reviews  should  be 
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made  available  to  the  developers  of  the  respective  versions  of  the  model 
schemas  so  that  they  may  mature  their  versions  making  them  stronger  and  more 
understandable  to  the  many  communities  of  interest  that  will  be  implementing 
them  in  the  near  future. 

This  work  began  with  a  focus  on  improving  the  data  interchange  abilities 
of  current  command  and  control  systems  and  simulations  so  that  critical  training 
might  be  accomplished  during  this  time  of  war.  Originally  the  training  envisioned 
was  the  type  necessary  to  prepare  soldiers  to  operate  in  the  stability  and  support 
operations  that  we  find  ourselves  in  today.  Messages  from  soldiers  involved  in 
OIF  and  OEF  underscored  the  need  for  tools  to  train  and  operate  in  that  difficult 
environment.  Six  months  later,  many  of  the  challenges  remain  the  same  and 
new  ones  have  surfaced  especially  the  need  to  maintain  a  training  environment 
during  ongoing  operations.  Correspondence  monitored  since  the  beginning  of 
this  work  indicates  that  steps  towards  the  interoperability  of  C2  systems  and 
simulations  have  taken  over  the  driver’s  seat  and  solutions  are  starting  to  appear. 
These  solutions  are  only  temporary  fixes  while  the  enduring  problem  remains. 

The  technologies  focused  on  in  this  research  were  the  Extensible  Markup 
Language  (XML),  the  Extensible  Stylesheet  Language  for  Transformation  (XSLT) 
and  the  Flexible  Asymmetric  Simulation  Technologies  (FAST)  Toolbox,  the 
Command  and  Control  Information  Exchange  Data  Model  (C2IEDM)  and  the 
Model  Driven  Architecture  (MDA).  Early  in  the  work  it  was  determined  that  while 
the  MDA  provided  a  promising  architecture  for  certain  software  development  it 
was  not  suitable  for  the  work  to  be  undertaken  here.  The  C2IEDM  was 
examined  and  utilized  with  great  success  and  is  the  leading  data  model  to  be 
used  within  the  DoD.  The  deliverable  was  an  exemplar  to  show  that  by  using 
XML,  XSLT  and  C2IEDM  data  could  be  represented,  transformed  and 
interchanged  between  C2  systems  and  simulation  technologies.  This  was  done 
successfully  and  it  has  been  shown  that  both  XML  and  XSLT  are  powerful  and 
relatively  easy  to  use  and  that  they  provide  solid  solutions  to  part  of  the  problem 
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of  interoperability,  data  representation  and  transformation.  C2IEDM  is  the  lynch 
pin  that  is  going  to  connect  C4ISR  systems  and  simulations  correctly  and 
completely  in  the  future. 
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APPENDIX  A.  UOB  SCHEMA  VERSION  7.7 


The  following  document  is  the  schema  used  to  validate  information 
entering  and  exiting  the  UOB  DAT.  It  was  provided  by  the  DMSO  personnel 
responsible  for  maintaining  the  UOB  toolset.  Further  information  about  the  UOB 
toolset  can  be  found  at  http://www.msiac.dmso.mil/UOB. 

<?xml  version="1.0"  encoding="UTF-8"?> 

<!--  edited  with  XMLSPY  v2004  rel.  3  U  (http://www.xmlspy.com)  by  JZanakos  (Dynamics 
Research  Corp)  --> 

<!--  edited  with  XML  Spy  v4.4  U  (http://www.xmlspy.com)  by  Joseph  E.  Eck  (Computing 
Technologies,  lnc.)--> 

<!~Changed  Unit  Name  to  optional  from  required.  Changed  Relatinship  from  required  to 
optional.  Changed  DataSource  from  required  to  optional  --> 

<!--  Added  the  optional  field  ParentOrg  --> 

<xs:schema  xmlns:xs="http://www. w3.org/2001/XMLSchema"  elementFormDefault="qualified"> 
<xs:element  name- 'UOB"> 

<xs:annotation> 

<xs:documentation>This  element  contains  all  UOB  data.</xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  ref="ForceStructurelnformation"  minOccurs="0"/> 

<xs:element  ref="Relationships"  minOccurs="0"/> 

<xs:element  ref="Units"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element  name="Unit"> 

<xs:annotation> 

<xs:documentation>DataSource  also  applies  to  Equipment,  Aircraft  and  Personnel 
Resources,  but  is  not  defined  for  each.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name="Name"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  name  of  the  unit.  For  MIDB 
units:  Translated  unit  name  or  identification  given  the  unit  by  appropriate  authority  or  orders  as 
used  in  official  orders  or  communications  within  the  national  military  or  civilian  establishment  of 
the  country  of  allegiance.  A  unit  name  must  be  established  for  every  unit  in  the  data  base.  For 
each  Unit  logical  record,  unit  naming  conventions  established  in  production  programs  should  be 
employed.  If  official  sources  are  not  available,  the  unit  name  believed  most  correct  is  used,  a 
unit's  primary  designation  usually  includes  service  specialty  and  command 
echelon. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="60"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 
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<xs:element  name="Present"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>This  is  a  continer  element  for  Present  location 
data.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name="Name"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  present  Name  of  the 
geographic  location  where  the  Unit  is  presently  located.  For  MIDB  units  this  is  the  location 
name  for  the  present  coordinates. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxl_ength  value="24"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Latitude"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Present  Unit  latitude  of  the  geographic 

location.  </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxl_ength  value="7"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Longitude"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Present  Unit  longitude  of  the  geographic 

location.  </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxl_ength  value="8"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element  name="Home"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>This  is  a  container  element  for  Home  location 
data.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name="Name"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  name  of  the 
geographic  location  where  the  Unit  is  garrisoned.  For  MIDB  units  this  is  the  location  name  of 
the  coordinates.</xs:documentation> 
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</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="24"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Latitude"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The  latitude  of  the  geographic  location  where 
the  Unit  is  garrisoned. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="7"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Longitude"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The  longitude  of  the  geographic  location 
where  the  Unit  is  garrisoned. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="8"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element  name="TypeCode"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A  five-character  alphanumeric  code  that  uniquely 
identifies  each  type  unit  of  the  U.S.  Armed  Forces.  The  first  position  of  Unit  Type  Code  (UTC) 
applies  to  all  the  US  Services.  The  UTC  is  a  5-character  A/N  code  that  is  associated  with  and 
allows  each  type  organization  to  be  categorized  into  a  class  having  common  characteristics.  The 
first  character  of  the  UTC,  as  described  below,  identifies  the  functional  category  of  the  unit.  Each 
Service  may  define  the  function  differently  or  may  not  have  a  valid  use  for  the  code.  Therefore, 
each  Service  functional  definition  is  provided  for  the  first  position  of  the  UTC  as  appropriate.  The 
remaining  four  characters  are  Service  assigned  codes. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxl_ength  value="5"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="DescriptionCode"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>For  US  Units  this  is  a  3  Character  Unit  Description  Code 
(UDC)  associated  with  the  unit  showing  unit  status  (Combat,  Combat  Support,  Combat  Service 
Support,  Active  Duty,  National  Guard,  or  Reserve). </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 
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<xs:restriction  base="xs:string"> 

<xs:maxLength  value="3"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="LevelCode"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A  three-letter  alphanumeric  code  used  to  specify  the 
organizational  level  (echelon)  of  the  Unit.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="3"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="TotalPersonnel"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>This  is  a  container  element  for  unit  personnel 
data.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name-'Authorized"  type="xs:short"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  quantity  of  authorized 
personnel  of  the  unit.  For  MIDB  units  this  is  relative  to  the  parent  entity,  the  total  number  of 
military  personnel  assessed  to  be  war  authorized  (WA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name-'OnHand"  type="xs:short"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  quantity  of  personnel 
present  for  duty  in  the  unit.  For  MIDB  units  this  is  relative  to  the  parent  entity,  the  total  number 
of  military  personnel  assessed  to  be  on-hand  (OH).</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element  name="CountryCode"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>State/Country  code  associated  with  the  geographic 
location  of  the  Unit.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="2"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Ship"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>This  is  a  container  element  for  Ship 
data.</xs:documentation> 

</xs:annotation> 
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<xs:complexType> 

<xs:sequence> 

<xs:element  name="Category"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>For  the  US  Navy  this  is  the  Navy  category 
type  of  ship.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="6"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="CategoryName"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The  Navy  category  name  of 

ship.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="56"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="HullNumber"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A  unique  ship  type  and  number  located  on  the 
Hull  of  a  ship.  It  is  composed  of  the  type  of  ship  ie  SSBN  and  a  number  ie  726  or  the  CV 
63.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxl_ength  value="4"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Class"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A  Navy  class  of  ships  which  other  like  ships 
are  associated  ie  the  Ohio  Class. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxl_ength  value="25"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element  name="SRC"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>This  is  a  container  element  for  SRC 
data.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 
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<xs:sequence> 

<xs:element  name="Code"  minOccurs="0"> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="9"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Name"  minOccurs="0"> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="32"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element  name="OpfacRule"  minOccurs="0"> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name="Code"  minOccurs="0"> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="5"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Title"  minOccurs="0"> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="46"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element  name="SymbolCode"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Mil-Std  2525-B  Symbolic  Codes</xs:documentation> 
</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="15"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Rolledup"  minOccurs="0"> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="1"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Subtracted"  minOccurs="0"> 
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<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="1"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="ParentOrg"  type="xs:string"  minOccurs="0"/> 

<xs:element  name="ORG_EID_S"  type="xs:double"  minOccurs="0"/> 

<xs:element  ref="Resource"  minOccurs="0"  maxOccurs="unbounded"/> 
</xs:sequence> 

<xs:attributeGroup  ref="UnitldentificationCode7> 

<xs:attribute  name="dataSource"  use="optional"> 

<xs:annotation> 

<xs:documentation>The  source  of  the  unit  data  ie  Conventional  Forces  Data 
Base  (CFDB),  Defense  Intelligence  Agency's  (DIA),  Moderized  Intergrated  Data  Base  (MIDB), 
Conventional  Forces  Europe  (CFE),  Generic,  or  the  National  Ground  Intelligence  Center's  (NGIC) 
ForceTracking  Information  System  (FORTRIS)  and  others. </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxl_ength  value="10"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

<xs:element  name- 'Units"> 

<xs:annotation> 

<xs:documentation>This  is  a  grouping  element  for  Units. </xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  ref="Unit"  minOccurs="0"  maxOccurs="unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element  name="Relationships"> 

<xs:annotation> 

<xs:documentation>This  is  a  grouping  element  for  Relationships. </xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name="Relationship"  maxOccurs="unbounded"> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name="Description"  type="xs:string"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>A  description  of  the 
relationship. </xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name="Assigned"  minOccurs="0"> 

<xs:complexType> 

<xs:sequence> 

<xs:element  ref="UnitNode"  maxOccurs="unbounded"/> 
</xs:sequence> 
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<xs:attribute  name-'type"  type="xs:string"  use="optional"/> 
</xs:complexType> 

</xs:element> 

<xs:element  name="Unassigned"  minOccurs="0"> 

<xs:complexType> 

<xs:sequence> 

<xs:element  ref="UnitNode"  minOccurs="0" 

maxOccurs="unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

<xs:attribute  name="type"  type="xs:string"  use="required"/> 
</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:attributeGroup  name="UnitldentificationCode"> 

<xs:attribute  name="UIC"  use="optional"> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="15"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:attribute> 

</xs:attributeGroup> 

<xs:element  name- 'UnitNode"> 

<xs:annotation> 

<xs:documentation>Represents  the  position  of  a  Unit  in  a  relationship  hierarchy.  The 
root  UnitNode  is  implicitly  defined  and  multiple  roots  are  allowed. </xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  ref="UnitNode"  minOccurs="0"  maxOccurs="unbounded"/> 
</xs:sequence> 

<xs:attribute  name="UIC"  type="xs:string"  use="optional"/> 

</xs:complexType> 

</xs:element> 

<xs:element  name-'ForceStructurelnformation"  nillable="true"> 

<xs:annotation> 

<xs:documentation>lnformation  about  the  Force  Structure. </xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence  minOccurs="0"> 

<xs:element  name="Name"  type="xs:string"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The  name  of  the  Force  Structure. </xs:documentation> 
</xs:annotation> 

</xs:element> 

<xs:element  name="FileName"  type="xs:string"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The  file  name  of  the  Force 
Structure. </xs:documentation> 

</xs:annotation> 

</xs:element> 
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<xs:element  name="Description"  type="xs:string"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A  brief  description  of  wha  the  Force  Structure 
is.</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name="Purpose"  type- 'xs:string"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>A  brief  description  for  why  the  Force  Structure  was 
created. </xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name="CreatedBy"  type="xs:string"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The  name  of  the  person  or  group  who  created  the  Force 
Structure. </xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name="CreationDate"  type="xs:date"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The  date  the  Force  Structure  was 
created. </xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name="LastModifiedBy"  type="xs:string"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>The  name  of  the  person  or  group  who  last  modified  the 
Force  Structure. </xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name="LastModifiedDate"  type="xs:date"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>The  date  of  the  last  modification  to  the  Force 
Structure. </xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

<xs:attribute  name="extracted"  type="xs:boolean"  use="optional"  default="false"> 
<xs:annotation> 

<xs:documentation>A  flag  to  indicate  whether  or  not  the  Force  Structure  was 
extracted.  Extracted  Force  Structures  can  have  only  one  relationship  type.</xs:documentation> 
</xs:annotation> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

<xs:element  name- 'Resource"> 

<xs:annotation> 

<xs:documentation>This  is  a  grouping  element  for  all  Resources. </xs:documentation> 
</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name="Personnel"  minOccurs="0"  maxOccurs="unbounded"> 
<xs:annotation> 

<xs:documentation>This  is  a  container  element  for  Personnel  resource 
data.</xs:documentation> 

</xs:annotation> 
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<xs:complexType> 

<xs:sequence> 

<xs:element  name="Description"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>The  description  of  a  military  occupational 
specialty  code  of  a  person  in  a  military  unit.  This  field  is  not  used  in  MIDB.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="1 1 0"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name-'Grade"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Pay  grade  of  personnel  assigned  to  a  unit. 

This  field  is  not  used  in  MIDB.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="3"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Required"  type="xs:short"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  quantity  of  personnel 
required  by  the  Unit  to  perform  its  wartime  mission.  For  MIDB  units  this  is  relative  to  the  parent 
entity,  the  total  number  of  military  personnel  assessed  to  be  war  authorized 
(WA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name-'Authorized"  type="xs:short"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  quantity  of  personnel 
to  be  assigned  to  the  Unit  to  perform  its  peacetime  mission.  For  MIDB  units  this  is  relative  to  the 
parent  entity,  the  total  number  of  military  personnel  assessed  to  be  peacetime  authorized 
(PA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name-'OnHand"  type="xs:short"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  quantity  of  personnel 
present  for  duty  in  the  unit.  For  MIDB  units  this  is  relative  to  the  parent  entity,  the  total  number 
of  military  personnel  assessed  to  be  on-hand  (OH).</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

<xs:attribute  name="code"  use="required"> 

<xs:annotation> 

<xs:documentation>Military  Occupation  Specialty  (MOS)  code  or  job 
code  of  personnel  assigned  to  a  military  unit.  This  Field  is  not  used  in 
MIDB.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 
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<xs:maxl_ength  value="7"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

<xs:element  name="Equipment"  minOccurs="0"  maxOccurs="unbounded"> 
<xs:annotation> 

<xs:documentation>This  is  a  container  element  for  Equipment  resource 
data.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name-'Description"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Equipment  nomenclature  associated  with  the 
equipment  code.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="65"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Required"  type="xs:short"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For  US  units  thsi  is  the  quantity  of  equipment 
required  by  the  Unit  to  perform  its  wartime  mission.  For  MIDB  units  this  is  relative  to  the  parent 
entity,  the  total  number  of  military  equipment  assessed  to  be  war  authorized 
(WA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name-'Authorized"  type="xs:short"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  quantity  of  equipmentl 
to  be  assigned  to  the  Unit  to  perform  its  peacetime  mission.  For  MIDB  units  this  is  relative  to  the 
parent  entity,  the  total  number  of  military  equipment  assessed  to  be  peacetime  authorized 
(PA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name-'OnHand"  type="xs:short"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  quantity  of  equipment 
on  hand  in  the  unit.  For  MIDB  units  this  is  relative  to  the  parent  entity,  the  total  number  of 
military  equipment  assessed  to  be  on-hand  (OH).</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

<xs:attribute  name="code"  use="required"> 

<xs:annotation> 

<xs:documentation>Unique  code  assigned  to  each  piece  of 
equipment.  </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxl_ength  value="15"/> 
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</xs:restriction> 

</xs:simpleType> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

<xs:element  name="Aircraft"  minOccurs-'O"  maxOccurs="unbounded"> 
<xs:annotation> 

<xs:documentation>This  is  a  container  element  for  Aircraft  resource 
data.</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name="Description"  minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Aircraft  nomenclature  associated  with  each 
aircraft  code.</xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value- '48"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="Required"  type="xs:short"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  quantity  of  aircraft 
required  by  the  Unit  to  perform  its  wartime  mission.  For  MIDB  units  this  is  relative  to  the  parent 
entity,  the  total  number  of  military  aircraft  assessed  to  be  war  authorized 
(WA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name-Authorized"  type="xs:short"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  quantity  of  aircraftl  to 
be  assigned  to  the  Unit  to  perform  its  mission.  For  MIDB  units  this  is  relative  to  the  parent 
entity,  the  total  number  of  military  aircraft  assessed  to  be  peacetime  authorized 
(PA).</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element  name-'OnHand"  type="xs:short"  minOccurs="0"> 
<xs:annotation> 

<xs:documentation>For  US  units  this  is  the  quantity  of  aircraft  on 
hand  in  the  unit.  For  MIDB  units  this  is  relative  to  the  parent  entity,  the  total  number  of  military 
aircraft  assessed  to  be  on-hand  (OH).</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

<xs:attribute  name="code"  use="required"> 

<xs:annotation> 

<xs:documentation>A  unique  code  that  is  assigned  to  each 
aircraft.  </xs:documentation> 

</xs:annotation> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:maxLength  value="15"/> 

</xs:restriction> 
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</xs:simpleType> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:schema> 
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APPENDIX  B.  EXTRACTED  UOB  UNIT  FILE  VERSION  7.7 


This  unit  file  was  extracted  from  the  UOB  version  7.7.  It  serves  as  a 

representation  compliant  with  the  UOB  version  7.7  schema  used  during  the 

C2IEDM  to  UOB  transformation.  This  is  what  the  result  file  may  look  like  when 

the  transformation  is  completely  finished. 

<?xml  version="1.0"  encoding- 'UTF-8"?> 

<UOB  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="UOB  Schema  7.7.xsd"> 

<ForceStructurelnformation> 

<Name/> 

<FileName/> 

<Description/> 

<Purpose/> 

<CreatedBy/> 

<CreationDate>2004-04-15</CreationDate> 

<LastModifiedBy/> 

<LastModifiedDate>2004-04-15</LastModifiedDate> 

</ForceStructurelnformation> 

<Relationships> 

<Relationship  type="Operational  Control"> 

<Assigned> 

<UnitNode  UIC="WG2LA07> 

</Assigned> 

</Relationship> 

</Relationships> 

<Units> 

<Unit  UIC="WG2LA0"  dataSource="ARMYTOE"> 

<Name>1ST  SQDN  3D  ARMORED  CAVALRY,  A  CAV  TRP,  CAV  SQDN</Name> 
<TypeCode>  </TypeCode> 

<LevelCode>  </LevelCode> 

<TotalPersonnel> 

<Authorized>1 32</Authorized> 

<OnHand>1 32</OnHand> 

</TotalPersonnel> 

<SRC> 

<Code>17487L000</Code> 

<Name>CAV  TRP,  CAV  SGDN</Name> 

</SRC> 

<OpfacRule> 

<Code>AB200</Code> 

<Title>AR  CO/CAV  TRP  CDR  (TRACK)</Title> 

</OpfacRule> 

<SymbolCode>S*G*UCRVA-*****</SymbolCode> 

<Resource> 

<Personnel  code="92Y30"> 

<Description>SUPPLY  SGT </Description> 

<Grade>E6</Grade> 

<Required>1  </Required> 

<Authorized>  1  </Authorized> 

</Personnel> 
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<Personnel  code="92A10"> 

<Description>EQUIP  REC/PARTS  SP</Description> 
<Grade>E4</Grade> 

<Required>1  </Required> 

<Authorized>1  </Authorized> 

</Personnel> 

<Personnel  code- '19D10"> 

<Description>CARRIER  DRIVER</Description> 
<Grade>E4</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel  code="92A20"> 

<Description>EQUIP  REC/PARTS  SGT</Description> 
<Grade>E5</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code="92Y10"> 

<Description>ARMORER</Description> 

<Grade>E4</Grade> 

<Required>1</Required> 

<Authorized>1</Authorized> 

</Personnel> 

<Personnel  code="12C00"> 

<Description>COMMANDER</Description> 

<Grade>03</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code- '19D10"> 

<Description>VEHICLE  DRIVER</Description> 
<Grade>E3</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code="63T10"> 

<Description>BFV  SYS  AUTO  MECH</Description> 
<Grade>E3</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel  code="63T10"> 

<Description>BFV  SYS  AUTO  MECH</Description> 
<Grade>E4</Grade> 

<Required>1  </Required> 

<Authorized>1  </Authorized> 

</Personnel> 

<Personnel  code="12C00"> 

<Description>EXECUTIVE  OFFICER</Description> 
<Grade>02</Grade> 

<Required>1  </Required> 

<Authorized>1  </Authorized> 

</Personnel> 

<Personnel  code="19D20"> 

<Description>CFV  GUNNER</Description> 
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<Grade>E5</Grade> 

<Required>13</Required> 

<Authorized>13</Authorized> 

</Personnel> 

<Personnel  code- '19D10"> 

<Description>CFV  DRIVER</Description> 
<Grade>E4</Grade> 

<Required>13</Required> 

<Authorized>1 3</Authorized> 

</Personnel> 

<Personnel  code="63T10"> 

<Description>RECOVERY  VEH  OPR</Description> 
<Grade>E4</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code="19Z5M"> 

<Description>FIRST  SERGEANT</Description> 
<Grade>E8</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code="63T20"> 

<Description>BFV  SYS  AUTO  MECH</Description> 
<Grade>E5</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel  code="54B20"> 

<Description>NBC  NCO</Description> 
<Grade>E5</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code="19K10"> 

<Description>TANK  CREWMAN</Description> 
<Grade>E4</Grade> 

<Required>9</Required> 

<Authorized>9</Authorized> 

</Personnel> 

<Personnel  code="12C00"> 

<Description>PLATOON  LEADER</Description> 
<Grade>02</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel  code="45E10"> 

<Description>M1  ABRAMS  TK  TRT  MECH</Description> 
<Grade>E3</Grade> 

<Required>1  </Required> 

<Authorized>1  </Authorized> 

</Personnel> 

<Personnel  code="45E10"> 

<Description>M1  ABRAMS  TK  TRT  MECH</Description> 
<Grade>E4</Grade> 

<Required>1</Required> 
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<Authorized>1  </Authorized> 

</Personnel> 

<Personnel  code="19K40"> 

<Description>PLATOON  SERGEANT</Description> 
<Grade>E7</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel  code="19D10"> 

<Description>SCOUT</Description> 

<Grade>E3</Grade> 

<Required>12</Required> 

<Authorized>12</Authorized> 

</Personnel> 

<Personnel  code="19D10"> 

<Description>SCOUT</Description> 

<Grade>E4</Grade> 

<Required>12</Required> 

<Authorized>12</Authorized> 

</Personnel> 

<Personnel  code="1 1C10"> 

<Description>ASSISTANT  GUNNER</Description> 
<Grade>E3</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel  code="19K30"> 

<Description>TANK  CDR/MASTER  GUNNER</Description> 
<Grade>E6</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code="19K20"> 

<Description>GUNNER/ASSISTANT  TC</Description> 
<Grade>E5</Grade> 

<Required>9</Required> 

<Authorized>9</Authorized> 

</Personnel> 

<Personnel  code="1 1C40"> 

<Description>SECTION  LEADER</Description> 
<Grade>E7</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code="19D30"> 

<Description>SQUAD  LEADER</Description> 
<Grade>E6</Grade> 

<Required>4</Required> 

<Authorized>4</Authorized> 

</Personnel> 

<Personnel  code="19D40"> 

<Description>PLATOON  SERGEANT</Description> 
<Grade>E7</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 
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<Personnel  code="63E10"> 

<Description>M1  TANK  AUTO  MECH</Description> 
<Grade>E4</Grade> 

<Required>1  </Required> 

<Authorized>1  </Authorized> 

</Personnel> 

<Personnel  code="63E40"> 

<Description>M1  TANK  MAINT  SUPV</Description> 
<Grade>E7</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code="12B00"> 

<Description>PLATOON  LEADER</Description> 
<Grade>02</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel  code="1 1C10"> 

<Description>CARRIER  DRIVER</Description> 
<Grade>E4</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel  code="19D30"> 

<Description>SECTION  LEADER</Description> 
<Grade>E6</Grade> 

<Required>4</Required> 

<Authorized>4</Authorized> 

</Personnel> 

<Personnel  code="45T10"> 

<Description>BFVS  TURRET  MECH</Description> 
<Grade>E4</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code="45T20"> 

<Description>BFVS  TURRET  MECH</Description> 
<Grade>E5</Grade> 

<Required>1  </Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Personnel  code="1 1C10"> 

<Description>GUNNER</Description> 

<Grade>E4</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel  code="1 1C30"> 

<Description>SQUAD  LEADER</Description> 
<Grade>E6</Grade> 

<Required>2</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel  code="63E20"> 

<Description>RECOVERY  VEH  OPR</Description> 
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<Grade>E5</Grade> 

<Required>1</Required> 

<Authorized>1  </Authorized> 

</Personnel> 

<Personnel  code="19K10"> 

<Description>TANK  CREWMAN  (LOADER)</Description> 
<Grade>E3</Grade> 

<Required>9</Required> 

<Authorized>9</Authorized> 

</Personnel> 

<Personnel  code="19K30"> 

<Description>TANK  COMMANDER</Description> 

<Grade>E6</Grade> 

<Required>4</Required> 

<Authorized>4</Authorized> 

</Personnel> 

<Personnel  code="63T30"> 

<Description>BFV  SYS  MECH</Description> 

<Grade>E6</Grade> 

<Required>1</Required> 

<Authorized>  1  </Authorized> 

</Personnel> 

<Equipment  code-  N04732"> 

<Description>NIGHT  VISION  SIGHT  INDIVIDUAL  SERVED  WEAPON: 
AN/PVS-4</Description> 

<Required>12</Required> 

</Equipment> 

<Equipment  code="E03826"> 

<Description>ELECTRONIC  TEST  SET:  TS-4348/UV</Description> 
<Required>5</Required> 

</Equipment> 

<Equipment  code="W02526"> 

<Description>TESTER  AIR  FLOW:  USED  ON  VEHICLES  W/GAS 
PARTICULATE  FILTER  UNITS</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="R59023"> 

<Description>REELING  MACHINE  CABLE  HAND:  RL-31</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="U05008"> 

<Description>SPLICING  KIT  TELEPHONE  CABLE:  MK-356/G</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="B07126"> 

<Description>AXLE  CABLE  REEL:  RL-27</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="C18514"> 

<Description>COMPUTER  SET:  DIGITAL  OL-583/TYQ</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="T40405"> 

<Description>TAPE  READER  GENERAL  PURPOSE:  KOI- 
1 8/TSEC</Description> 

<Required>2</Required> 
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</Equipment> 

<Equipment  code="V31211"> 

<Description>TELEPHONE  SET:  TA-31 2/PT</Description> 
<Required>9</Required> 

</Equipment> 

<Equipment  code="R44999"> 

<Description>RADIO  SET:  AN/VRC-89F(C)</Description> 
<Required>7</Required> 

</Equipment> 

<Equipment  code="R31061"> 

<Description>RADIAC  SET:  AN/UDR-13</Description> 
<Required>28</Required> 

</Equipment> 

<Equipment  code="R56742"> 

<Description>REEL  EQUIPMENT:  CE-1 1</Description> 
<Required>18</Required> 

</Equipment> 

<Equipment  code="R30925"> 

<Description>RADIAC  SET:  AN/PDR-75</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="M60449"> 

<Description>MULTIMETER  DIGITAL:  AN/PSM-45</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="C68719"> 

<Description>CABLE  TELEPHONE:  WD-1/TT  DR-8  1/2  KM</Description> 
<Required>46</Required> 

</Equipment> 

<Equipment  code="C68856"> 

<Description>CABLE  TELEPHONE:  WD-1/TT  RL-159/U  2  KM</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="L91975"> 

<Description>MACHINE  GUN  CALIBER  .50:  HB  FLEXIBLE  (GROUND  AND 
VEHICLE)  W/E</Description> 

<Required>1 6</Required> 

</Equipment> 

<Equipment  code="R68146"> 

<Description>RADIO  SET:  AN/VRC-91F(C)</Description> 
<Required>14</Required> 

</Equipment> 

<Equipment  code="L67964"> 

<Description>LIGHTWEIGHT  DIGITAL  FACSIMILE:  AN/UXC-7</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="M12418"> 

<Description>MASK  CHEMICAL  BIOLOGICAL:  M40</Description> 
<Required>14</Required> 

</Equipment> 

<Equipment  code="R59160"> 

<Description>REELING  MACHINE  CABLE  HAND:  RL-39</Description> 
<Required>27</Required> 

</Equipment> 

<Equipment  code="D60801"> 
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<Description>DIGITAL  NON-SECURE  VOICE  TERMINAL  W/DIGITAL  DATA 
PORT:  TA-1042A/</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code-  N95862"> 

<Description>NAVIGATION  SET  SATILLITE  SYSTEMS:  AN/PSN- 

1 1</Description> 

<Required>30</Required> 

</Equipment> 

<Equipment  code="K53748"> 

<Description>HOSE  COT  RUB  LINE:  M-F  CPLG  1-1/2  IN  1-1/2  NPSH  25  FT 
LONG</Description> 

<Required>4</Required> 

</Equipment> 

<Equipment  code="C89145"> 

<Description>CAMOUFLAGE  SCREEN  SYSTEM:  WOODLAND  LT  WT  RADAR 
SCAT  W/O  SPT  SYS</Description> 

<Required>92</Required> 

</Equipment> 

<Equipment  code="T61494"> 

<Description>TRUCK  UTILITY:  CARGO/TROOP  CARRIER  1-1/4  TON  4X4  W/E 
(HMMWV)</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment  code="R20684"> 

<Description>RADIAC  SET:  AN/VDR-2</Description> 

<Required>1 1  </Required> 

</Equipment> 

<Equipment  code="C05701"> 

<Description>MONITOR  CHEMICAL  AGENT:</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="C89070"> 

<Description>CAMOUFLAGE  SCREEN  SUPPORT  SYSTEM: 
WOODLAND/DESERT  </Description> 

<Required>92</Required> 

</Equipment> 

<Equipment  code="R68044"> 

<Description>RADIO  SET:  AN/VRC-90F(C)</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="W51910"> 

<Description>TOOL  KIT  SMALL  ARMS  REPAIRMAN: 
ORDNANCE</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="A33020"> 

<Description>ALARM :  CHEMICAL  AGENT  AUTOMATIC  M22</Description> 
<Required>1 1  </Required> 

</Equipment> 

<Equipment  code="S64488"> 

<Description>SPEECH  SCTY  ECUIP  DIGITAL  SUBSCRIBER  VOICE 
TERMINAL:  TSEC/KY-68</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="W98825"> 
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<Description>TRAILER  TANK:  WATER  400  GALLON  1-1/2  TON  2  WHEEL 
W/E</Description> 

<Required>1  </Required> 

</Equipment> 

<Equipment  code="K24862"> 

<Description>HEATER  DUCT  TYPE  PTBL:  GAS  250000  BTU  WHL 
MTD</Description> 

<Required>1  </Required> 

</Equipment> 

<Equipment  code="A79381"> 

<Description>ANTENNA  GROUP:  OE-254()/GRC</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="E63728"> 

<Description>COMPASS  MAGNETIC  UNMOUNTED:  MIL 
GRADUATIONS</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment  code="W33004"> 

<Description>TOOL  KIT  GENERAL  MECHANICS:  AUTOMOTIVE</Description> 
<Required>9</Required> 

</Equipment> 

<Equipment  code="L44595"> 

<Description>LAUNCHER  GRENADE  40  MILLIMETER:  SGLE  SHOT  RIFLE 
MTD  DTCHBLE  W/E</Description> 

<Required>16</Required> 

</Equipment> 

<Equipment  code="T49947"> 

<Description>TENT :  LIGHTWEIGHT  MAINTENANCE  ENCLOSURE 
(LME)</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="T55957"> 

<Description>TERMINAL  RADIO-TELEPHONE  MOBILE  SUBSCRIBER: 
AN/VRC-97</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="U81707"> 

<Description>SWITCHBOARD  TELEPHONE  MANUAL:  SB- 
22/PT  </Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="M74364"> 

<Description>MOUNT  GUN:  RING  CAL  .50</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="R67296"> 

<Description>RADIO  SET:  AN/VRC-87F(C)</Description> 
<Required>4</Required> 

</Equipment> 

<Equipment  code="Z63141"> 

<Description>MAST  ANTENNA  10  METERS:  AB-XXX</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="C18446"> 

<Description>COMPUTER  SET:  DIGITAL  OL-582/TYQ</Description> 
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<Required>1  </Required> 

</Equipment> 

<Equipment  code="E70064"> 

<Description>COMP  UNIT  RCP:  TRK  2  WHL  PNEU  TIRES  GAS  DRVN  5  CFM 
175  PSI</Description> 

<Required>1  </Required> 

</Equipment> 

<Equipment  code="D1 1538"> 

<Description>CARRIER  COMMAND  POST:  LIGHT  TRACKED</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="W34648"> 

<Description>TOOL  KIT  CARPENTERS:  ENGINEER  SQUAD 
W/CHEST</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code-  N05482"> 

<Description>NIGHT  VISION  GOGGLE:  AN/PVS-7B</Description> 
<Required>90</Required> 

</Equipment> 

<Equipment  code="G18358"> 

<Description>GEN  SET:  DED  SKID  MTD  3KW  60HZ</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="T31872"> 

<Description>TELEPHONE  WIRE  WITH  REEL:  MX-10891/G</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="C05541"> 

<Description>CONTROL  RECEIVER-TRANSMITTER:  C- 
1 1 561  (C)/U</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment  code="D78555"> 

<Description>DATA  TRANSFER  DEVICE:  AN/CYZ-10</Description> 
<Required>44</Required> 

</Equipment> 

<Equipment  code="M18526"> 

<Description>MASK  CHEMICAL  BIOLOGICAL:  COMBATVEHICLE 
M42</Description> 

<Required>1 1 8</Required> 

</Equipment> 

<Equipment  code="R95035"> 

<Description>RIFLE  5.56  MILLIMETER:  M16A2</Description> 
<Required>25</Required> 

</Equipment> 

<Equipment  code="M75577"> 

<Description>MOUNT  TRIPOD  MACHINE  GUN:  HEAVY  CALIBER 

50</Description> 

<Required>6</Required> 

</Equipment> 

<Equipment  code="T25726"> 

<Description>TONE-SIGNALLING  ADAPTER:  TA-977(  )/PT</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="B67766"> 
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<Description>BINOCULAR:  MODULAR  CONSTRUCTION  MIL  SCALE 
RETICLE  7X50MM  W/E</Description> 

<Required>26</Required> 

</Equipment> 

<Equipment  code="P98152"> 

<Description>PISTOL  9MM  AUTOMATIC:  M9</Description> 
<Required>78</Required> 

</Equipment> 

<Equipment  code="W32593"> 

<Description>SHOP  ECUIPMENT  AUTO  MAINT  AND  REPAIR:  OM  COMMON 
NO  1  LESS  POWER</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="D10788"> 

<Description>DIGITAL  DATA  SET:  AN/PSG-7V1</Description> 
<Required>6</Required> 

</Equipment> 

<Equipment  code="G02341"> 

<Description>DETECTING  SET  MINE:  PTBL  METALLIC  (AN/PSS- 
1 1)</Description> 

<Required>4</Required> 

</Equipment> 

<Equipment  code-  N04596"> 

<Description>NIGHT  VISION  SIGHT  CREW  SERVED  WEAPON:  AN/TVS- 

5</Description> 

<Required>6</Required> 

</Equipment> 

<Equipment  code="R97234"> 

<Description>RIFLE  5  56  MILLIMETER:  M4</Description> 
<Required>48</Required> 

</Equipment> 

<Equipment  code="R45543"> 

<Description>RADIO  SET:  AN/VRC-92F(C)</Description> 
<Required>4</Required> 

</Equipment> 

<Equipment  code="T60081"> 

<Description>TRUCK  CARGO:  4X4  LMTV  W/E</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="T96564"> 

<Description>TRAILER  FLAT  BED:  M1082  TRLR  CARGO  LMTV 
W/DROPSIDES</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment  code="B49272"> 

<Description>BAYONET-KNIFE:  W/SCABBARD  FOR  M16A1 
RIFLE</Description> 

<Required>132</Required> 

</Equipment> 

<Equipment  code="C18234"> 

<Description>CARRIER  PERSONNEL  FULL  TRACKED:  ARMORED 
(RISE)</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment  code="T92889"> 
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<Description>TEST  SET:  ELECT  SYS  AN/PSM-95  FOR  SOLDIERS  PORT  ON- 
SYS  REP  TOOL</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment  code="R30895"> 

<Description>RADIO  SET:  AN/GRC-213</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="T06859"> 

<Description>TEST  SET:  COMMON  CORE  (STE-M1/FVS)</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="M92420"> 

<Description>MACHINE  GUN  7.62  MILLIMETER:  FIXED  RH 
FEED</Description> 

<Required>13</Required> 

</Equipment> 

<Equipment  code="L44031"> 

<Description>LAUNCHER  GRENADE  ARMAMENT  SUBSYSTEM: 
M257</Description> 

<Required>13</Required> 

</Equipment> 

<Equipment  code="K47623"> 

<Description>KY-99:  MINTERM</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="L44748"> 

<Description>LAUNCHER  GRENADE  ARMAMENT  SUBSYSTEM:  SCREEN 
RP  M259</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment  code="A10769"> 

<Description>ADAPTER  HARDWARE:  FVS  PECULIAR  (STE- 
M1/FVS)</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="R50681"> 

<Description>RECOVERY  VEHICLE  FULL  TRACKED:  MEDIUM</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="F60530"> 

<Description>FIGHTING  VEHICLE:  FULL  TRACKED  CAVALRY  HI 
SURVIVABILITY  (CFV)</Description> 

<Required>13</Required> 

</Equipment> 

<Equipment  code="V98788"> 

<Description>POWER  SUPPLY  VEHICLE:  HYP-57/TSEC</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="T60149"> 

<Description>TRUCK  CARGO:  4X4  LMTV  W/E  W/W</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="S35741"> 

<Description>SAW  CHAIN:  GAS  DRVN  BAR  FRAME 
W/ACCESS/COMPONENTS</Description> 
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<Required>4</Required> 

</Equipment> 

<Equipment  code="W48074"> 

<Description>TOOL  KIT  PIONEER  ENGINEER  COMBAT  PLATOON:  TOOLS 
FOR  MANUAL  LABOR</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="M74849"> 

<Description>MINI  EYESAFE  LASER  INFRARED  OBSERVATION  SET 
(MELIOS):  AN/PVS-6</Description> 

<Required>12</Required> 

</Equipment> 

<Equipment  code="L44612"> 

<Description>LAUNCHER  GRENADE  ARMAMENT  SUBSYSTEM: 
SCREENING  RED  PHOSPHO  M239</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="P06148"> 

<Description>PLAT OON  EARLY  WARNING  SYSTEM:  AN/TRS- 
2(V)</Description> 

<Required>6</Required> 

</Equipment> 

<Equipment  code="C96840"> 

<Description>CONTROL  REMOTE  LANDMINE  SYSTEM:  M71</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="T45593"> 

<Description>SIGHT  BORE  OPTICAL:</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="P07900"> 

<Description>PLOTTING  BOARD  INDIRECT  FIRE:  AZIMUTH</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="Y85377"> 

<Description>WRENCH  TORQUE:  3/4  IN  SQ  MALE  DRIVE  600  FT-LB 
CAPACITY</Description> 

<Required>3</Required> 

</Equipment> 

<Equipment  code="L92352"> 

<Description>MACHINE  GUN  7.62  MILLIMETER:  FIXED</Description> 
<Required>1 8</Required> 

</Equipment> 

<Equipment  code="P70517"> 

<Description>PURGING  KIT  FIRE  CONTROL:  ORG  MAINT</Description> 
<Required>1</Required> 

</Equipment> 

<Equipment  code="V35477"> 

<Description>TELESCOPE  STRAIGHT:  MILITARY</Description> 
<Required>12</Required> 

</Equipment> 

<Equipment  code="L44680"> 

<Description>LAUNCHER  GRENADE  SMOKE:  SCREENING  RP 
M250</Description> 

<Required>9</Required> 

</Equipment> 
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<Equipment  code="Y03104"> 

<Description>VIEWER  INFRARED:  AN/PAS-7</Description> 
<Required>12</Required> 

</Equipment> 

<Equipment  code="T58051"> 

<Description>TOOL  KIT  MECHANICS:</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="M68405"> 

<Description>MORTAR  120  MILLIMETERS:</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code-  N05050"> 

<Description>NIGHT  VISION  SIGHT  SET:  AN/UAS-1 1</Description> 
<Required>6</Required> 

</Equipment> 

<Equipment  code="B90494"> 

<Description>BORESIGHTING  EQUIPMENT  WEAPON:  MUZZLE 
ALIGNMENT</Description> 

<Required>9</Required> 

</Equipment> 

<Equipment  code="T  1 3305"> 

<Description>TANK  COMBAT  FULL  TRACKED:  120MM  GUN 
M1A2</Description> 

<Required>9</Required> 

</Equipment> 

<Equipment  code="K27594"> 

<Description>KIT  GROUND  HOP:  Ml  TANK</Description> 
<Required>1</Required> 

</Equipment> 

Equipment  code="W32182"> 

<Description>TOOL  KIT  ARTILLERY  MECHANICS:  ORD</Description> 
<Required>4</Required> 

</Equipment> 

<Equipment  code="A10837"> 

<Description>ADAPTER  HARDWARE:  Ml  PECULIAR  (STE- 
M1/FVS)</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="L92386"> 

<Description>MACHINE  GUN  7.62  MILLIMETER:  LIGHT 
FLEXIBLE</Description> 

<Required>12</Required> 

</Equipment> 

<Equipment  code="M68258"> 

<Description>MORTAR:  SUBCALIBER  INSERT  120  MILLIMETER 
M303</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment  code="C60294"> 

<Description>COMPUTER  SET  BALLISTICS:  MORTAR  M23</Description> 
<Required>2</Required> 

</Equipment> 

<Equipment  code="M51419"> 

<Description>MISSILE  SIMULATION  ROUND:  (TOW)</Description> 
<Required>12</Required> 
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</Equipment> 

<Equipment  code="C10990"> 

<Description>CARRIER  120  MILLIMETER  MORTAR:  SELF  PROPELLED 
ARMORED</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment  code="E98103"> 

<Description>ELEC  TRANSFER  KEYING  DEVICE  ETKD:  KYK- 
13/TSEC</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="F91627"> 

<Description>DEMOLITION  SET  EXPLOSIVE:  INITIATING  NON 
ELECTRIC</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment  code="L40063"> 

<Description>LASER  INFRARED  OBSERVATION  SET:  AN/GVS- 

5</Description> 

<Required>6</Required> 

</Equipment> 

<Equipment  code="A22496"> 

<Description>AIMING  CIRCLE:</Description> 

<Required>2</Required> 

</Equipment> 

<Equipment  code="A70522"> 

<Description>ADAPTER  TEST  ELECTRICAL  SYSTEM  BREAKOUT:  Ml 
TANK</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="P49587"> 

<Description>PJH  SURFACE  VECHILE  RADIO  SET:  ANA/SQ-2(V)1 
(PJHI)</Description> 

<Required>8</Required> 

</Equipment> 

<Equipment  code="T62405"> 

<Description>TOOL  SET  BATTALION  MAINTENANCE  TEAM:  ARMOR/MECH 
INF/FLD  ARTY</Description> 

<Required>1</Required> 

</Equipment> 

<Equipment  code="Q03468"> 

<Description>QUADRANT  FIRE  CONTROL:  GUNNERS</Description> 
<Required>1 1  </Required> 

</Equipment> 

<Equipment  code="K41392"> 

<Description>KIT  GROUND  HOP:  IFV/CFV</Description> 
<Required>1</Required> 

</Equipment> 

</Resource> 

</Unit> 

</Units> 

</UOB> 
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APPENDIX  C.  C2IEDM  TO  UOB  XSLT 


This  is  the  XSLT  created  by  the  author  to  extract  unit  data  from  a  C2IEDM 
instance  document  and  transform  it  into  a  UOB  schema  compliant  result 
document  that  can  be  used  within  the  FAST  project  as  an  initialization  file  for  a 
simulation. 

<?xml  version="1.0"  encoding="UTF-8"?> 

<xsl:stylesheet  version="1 .0"  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 

<xsl:output  method="xml"  version="1 ,0"/> 

<xsl template  match- 7"> 

<xsl:element  name="UOB"> 

<xsl:element  name-'ForceStructurelnformation"> 

<xsl:call-template  name="FileHeader"/> 

</xsl:element> 

<xsl:element  name- 'Units"> 

<xsl:apply-templates  select-'BattlespaceData/OBJECT- 
ITEM/ORGANISATION/UNIT/unit-formal-abbreviated-name"/> 

</xsl:element> 

</xsl:element> 

</xsl:template> 

<xsl:template  name="FileHeader"> 

<xsl:element  name="Name"/> 

<xsl:element  name="FileName"/> 

<xsl:element  name="Description">Unit  document  generated  using  XSLT  on  XML  C2IEDM 
Ver6.1  model</xsl:element> 

<xsl:element  name="Purpose"/> 

<xsl:element  name="CreatedBy">Transformation  of  C2IEDM  Source  File  to  the  UOB 
Format</xsl:element> 

<xsl:element  name="CreationDate">2004-04-15</xsl:element> 

<xsl:element  name="LastModifiedBy"/> 

<xsl:element  name="LastModifiedDate">2004-08-10</xsl:element> 

</xsl:template> 

<xsl:template  match- 'unit-formal-abbreviated-name"> 

<xsl:element  name="Unit"> 

<xsl:attribute  name="UIC"/> 

<xsl:attribute  name="dataSource"/> 

<xsl:element  name- 'Name"> 

<xsl:value-of  select="."/> 

</xsl:element> 

<xsl:variable  name="ObjectltemlD"  select- /../object-item-id"/> 

<xsl:variable  name="ObjectTypelD"  select-'.. /OBJECT-ITEM-TYPE/object-type- 

id"/> 

<xsl:call-template  name="RelativeUnitLocation"> 

<xsl:with-param  name="UnitObjectltemlD"  select="$ObjectltemlD"/> 
<xsl:with-param  name-'UnitObjectltemLocationlD"  select=".. /OBJECT-ITEM- 
LOCATION/location-id"/> 

</xsl:call-template> 

<xsl:call-template  name-'UnitTypeCategoryCode"> 

<xsl:with-param  name="OTypelD"  select="$ObjectTypelD"/> 

</xsl:call-template> 

<xsl:call-template  name-'UnitTypeSizeCode"> 
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<xsl:with-param  name="ObjTyplD"  select="$ObjectTypelD"/> 
</xsl:call-template> 

<xsl:element  name="Resource"> 

<xsl:call-template  name="PersonnelHoldings"/> 

<xsl:call-template  name="EquipmentHoldings"/> 

</xsl:element> 

</xsl:element> 

</xsl:template> 

<xsl:template  name="PersonnelHoldings"> 

<xsl:for-each  select="../../../HOLDING"> 

<xsl:variable  name="holdingObjectTypelD"  select="object-type-id"/> 
<xsl:variable  name="holdingObjectltemlD"  select="object-item-id"/> 
<xsl:for-each  select="../../OBJECT-TYPE"> 

<xsl:variable  name="objectTypelD"  select- 'object-type-id"/> 

<xsl:if  test="$objectTypelD  =  $holdingObjectTypelD"> 

<xsl:if  test="object-type-category-code  /*  [local-name()  =  'PE']"> 
<xsl:element  name="Personnel"> 

<xsl:attribute  name="code"><xsl:value-of  select="object-type- 

n  a  m  e"/>  </xs  I :  attri  b  u  te  > 

<xsl:call-template  name="PersonnelTemplate"/> 
<xsl:call-template  name="PersonnelHoldingNumbersTemplate"/> 
</xsl:element> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:for-each> 

</xsl:template> 

<xsl:template  name="PersonnelTemplate"> 

<xsl:element  name="Description7> 

<xsl:element  name="Grade"> 

<xsl:choose> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'0F1  ']">01/02</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OF2']">03</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OF3']">04</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OF4']">05</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OF5']">06</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OF6']">07</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OF7']">08</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OF8']">09</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OF9']">10</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'0R1  ']">E1  </xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OR2']">E2</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OR3']">E3</xsl:when> 
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<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OR4']">E4</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OR5']">E5</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OR6']">E6</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OR7']">E7</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'0R8']">W1</xsl:when> 

<xsl:when  test="PERSON-TYPE/person-type-rank-code/*  [local-name()  = 
'OR9']">W2</xsl:when> 

<xsl:otherwise>Unknown</xsl:otherwise> 

</xsl:choose> 

</xsl:element> 

</xsl:template> 

<xsl:template  name="EquipmentHoldings"> 

<xsl:for-each  select="../../../HOLDING"> 

<xsl:variable  name="holdingObjectTypelD"  select="object-type-id"/> 

<xsl:for-each  select="../../OBJECT-TYPE"> 

<xsl:variable  name="objectTypelD"  select- 'object-type-id"/> 

<xsl:if  test="$objectTypelD  =  $holdingObjectTypelD"> 

<xsl:if  test- 'object-type-category-code  /*  [local-name()  =  'MA']"> 
<xsl:apply-templates  select="MATERIEL-TYPE"/> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:for-each> 

</xsl:template> 

<xsl template  match="MATERIEL-TYPE"> 

<xsl:if  test="materiel-type-category-code  /*  [local-name()  =  'EQ']"> 

<xsl:element  name="Equipment"> 

<xsl:attribute  name="code"><xsl:value-of  select-'.. /../object-type- 
name"/></xsl:attribute> 

<xsl:apply-templates  select="./EQUIPMENT-TYPE7> 

<xsl:element  name="Required"> 

<xsl:value-of  select-’.. /HOLDING/holding-operational-quantity"/> 
</xsl:element> 

<xsl:element  name="Authorized"> 

<xsl:value-of  select=”../HOLDING/holding-total-quantity"/> 

</xsl:element> 

</xsl:element> 

</xsl:for-each> 

</xsl:if> 

</xsl:template> 

<xsl:template  name="EquipmentType"> 

<xsl:element  name="Description"> 

<xsl:choose> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  AIRCFT']"> 
<xsl:value-of  select="AIRCRAFT-TYPE/aircraft-type-subcategory- 

code/7@value"> 

</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'ELCTRN']"> 
<xsl:value-of  select="ELECTRONIC-EQUIPMENT-TYPE/electronic-equipment- 
type-subcategory-code/7@value"> 
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</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'ENGEQ']"> 
<xsl:value-of  select="ENGINEERING-EQUIPMENT-TYPE/engineering- 
equipment-type-category-code/*/@value"> 

</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'LNDWEP']"> 
<xsl:value-of  select="LAND-WEAPON-TYPE/land-weapon-type-category- 

code/*/@value"> 

</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'MISCEQ']"> 
<xsl:value-of  select="MISCELLANEOUS-EQUIPMENT-TYPE/miscellaneous- 
equipment-type-category-code/*/@value"> 

</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'NBCEQ']"> 
<xsl:va!ue-of  select-'NBC-EQUIPMENT-TYPE/nbc-equipment-type-category- 

code/*/@value"> 

</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'RAIL']"> 
<xsl:value-of  select="RAILCAR-TYPE/railcar-type-category-code/*/@value"> 
</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'VEHCLE']"> 
<xsl:value-of  select="VEHICLE-TYPE/vehicle-type-category-code/*/@value"> 
</xsl:when> 

<xsl:when  test="equipment-type-category-code  /*  [local-name()  =  'VESSEL']"> 
<xsl:value-of  select="VESSEL-TYPE/vessel-type-subcategory-code/*/@value"> 
</xsl:when> 

<xsl:otherwise/> 

</xsl:choose> 

</xsl:element> 

</xsl:template> 

<xsl:template  name="PersonnelHoldingNumbersTemplate"> 

<xsl:element  name="Required"> 

<xsl:value-of  select="HOLDING/holding-operational-quantity"/> 

</xsl:element> 

<xsl:element  name="Authorized"> 

<xsl:value-of  select="HOLDING/holding-total-quantity"/> 

</xsl:element> 

</xsl:template> 

<xsl:template  name="UnitTypeCategoryCode"> 

<xsl:param  name="OTypelD"/> 

<xsl:element  name="DescriptionCode"> 

<xsl:for-each  select="../../../../OBJECT-TYPE"> 

<xsl:variable  name="LocalObjectTypelD"  select="object-type-id"/> 

<xsl:if  test="$OTypelD  =  $LocalObjectTypelD"> 

<xsl:if  test-'object-type-category-code/*  [local-name()  =  '0R']"> 

<xsl:if  test="ORGANISATION-TYPE/organisation-type-category-code/* 
[local-name()  =  'GVTORG']"> 

<xsl:if  test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/government-organisation-type-category-code/*  [local-name()  =  'MILORG']"> 

<xsl:if  test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/military-organisation-type-category- 
cod el*  [local-name()  =  'UNIT']"> 

<xsl:choose> 

<xsl:when  test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category- 
code/*  [local-name()  =  'COMBAT']">AAC</xsl:when> 
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<xsl:when  test- 'ORGANISATION-TYPE/GOVERNMENT- 
ORGAN  ISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category- 
code/*  [local-name()  =  'COMSER']">AAV</xsl:when> 

<xsl:when  test- 'ORGANISATION-TYPE/GOVERNMENT- 
ORGAN  ISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-category- 
cod el*  [local-name()  =  'COMSPT']">AAS</xsl:when> 

<xsl:otherwise>U</xsl:otherwise> 

</xsl:choose> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 

<xsl:template  name="UnitTypeSizeCode"> 

<xsl:param  name="ObjTyplD"/> 

<xsl:element  name="LevelCode"> 

<xsl:for-each  select="../../../../OBJECT-TYPE"> 

<xsl:variable  name-'LocalObjTypID"  select="object-type-id"/> 

<xsl:if  test="$ObjTyplD  =  $LocalObjTyplD"> 

<xsl:if  test="object-type-category-code/*  [local-name()  =  'OR']"> 

<xsl:if  test-'ORGANISATION-TYPE/organisation-type-category-code/* 
[local-name()  =  'GVTORG']"> 

<xsl:if  test="ORGANISATION-TYPE/GOVERNMENT-ORGANISATION- 
TYPE/government-organisation-type-category-code/*  [local-name()  =  'MILORG']"> 

<xsl:if  test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/military-organisation-type-category- 
code/*  [local-name()  =  'UNIT']"> 

<xsl:choose> 

<xsl:when  test- 'ORGANISATION-TYPE/GOVERNMENT- 
ORGAN  ISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'ARMY']">A</xsl:when> 

<xsl:when  test- 'ORGAN  ISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'AGP']">AG</xsl:when> 

<xsl:when  test- 'ORGAN  ISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'BN']">BN</xsl:when> 

<xsl:when  test- 'ORGAN  ISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'BDE']">BDE</xsl:when> 

<xsl:when  test-'ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'CBTTM']">CO</xsl:when> 

<xsl:when  test-'ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'COY']">CO</xsl:when> 

<xsl:when  test- 'ORGAN  ISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'CORPS']">CPS</xsl:when> 

<xsl:when  test-'ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'DIV']">DIV</xsl:when> 
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<xsl:when  test- 'ORGAN  ISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'FLEET']">FLT</xsl:when> 

<xsl:when  test- 'ORGAN  ISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'FLIGHT']">FT</xsl:when> 

<xsl:when  test- 'ORGAN  ISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'PLT']">PLT</xsl:when> 

<xsl:when  test="ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'RGT']">RGT</xsl:when> 

<xsl:when  test-'ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'REGION']">REG</xsl:when> 

<xsl:when  test- 'ORGAN  ISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'SECT']">SEC</xsl:when> 

<xsl:when  test- 'ORGAN  ISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'SQUAD']">SQD</xsl:when> 

<xsl:when  test- 'ORGAN  ISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'SQDRNA']">SQ</xsl:when> 

<xsl:when  test-'ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'SQDRNL']">SQ</xsl:when> 

<xsl:when  test-'ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'TEAM']">TM</xsl:when> 

<xsl:when  test-'ORGANISATION-TYPE/GOVERNMENT- 
ORGANISATION-TYPE/MILITARY-ORGANISATION-TYPE/UNIT-TYPE/unit-type-size-code/* 
[local-name()  =  'WING']">WG</xsl:when> 

<xsl:otherwise>U</xsl:otherwise> 

</xsl:choose> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 

<xsl:template  name="RelativellnitLocation"> 

<xsl:param  name="UnitObjectltemlD"/> 

<xsl:param  name="UnitObjectltemLocationlD7> 

<xsl:element  name- 'Present"> 

<xsl:element  name="Name">Current  Loc</xsl:element> 

<xsl:for-each  select="../../../OBJECT-ITEM-LOCATION"> 

<xsl:variable  name-'ObjectltemLocationObjectltemlD"  select="object-item-id"/> 
<xsl:variable  name-'ObjectltemLocationLocationlD"  select="location-id"/> 
<xsl:for-each  select="../../LOCATION"> 

<xsl:variable  name-'LocationID"  select="location-id"/> 

<xsl:if  test="$UnitObjectltemlD  =  $ObjectltemLocationObjectltemlD"> 

<xsl:if  test="$UnitObjectltemLocationlD  =  $LocationlD"> 

<xsl:element  name- 'Latitude"> 
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latitude-coordinate"/> 


<xsl:value-of  select="POINT/ABSOLUTE-POINT/absolute-point 


</xsl:element> 

<xsl:element  name="Longitude"> 

<xsl:value-of  select="POINT/ABSOLUTE-POINT/absolute-point 

longitude-coordinate"/> 

</xsl:element> 

</xsl:if> 

</xsl:if> 

</xsl:for-each> 

</xsl:for-each> 

</xsl:element> 

</xsl:template> 

</xsl:stylesheet> 
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APPENDIX  D.  C2IEDM  TO  UOB  RESULT  DOCUMENT 


This  is  the  result  document  generated  when  the  XSLT  in  Appendix  C  was 
used  on  a  sample  C2IEDM  source  file  (instance  document).  Due  to  the  size  of 
the  source  file  it  is  not  included  here  but  is  available  upon  request. 

<?xml  version="1.0"  encoding="UTF-8"?> 

<UOB> 

<ForceStructurelnformation> 

<Name/> 

<FileName/> 

<Description>Unit  document  generated  using  XSLT  on  XML  C2IEDM  Ver  6.1 
model</Description> 

<Purpose/> 

<CreatedBy>Transformation  of  C2IEDM  Source  File  to  the  UOB  Format</CreatedBy> 
<CreationDate>2004-04-15</CreationDate> 

<LastModifiedBy/> 

<LastModifiedDate>2004-08-10</LastModifiedDate> 

</ForceStructurelnformation> 

<Units> 

<Unit  UIC=""  dataSource=""> 

<Name>A  1/3  ACR</Name> 

<Present> 

<Name>Current  Loc</Name> 

<Latitude>lat</Latitude> 

<Longitude>long</Longitude> 

</Present> 

<DescriptionCode>AAC</DescriptionCode> 

<LevelCode>CO</LevelCode> 

<Resource> 

<Personnel  code-'12C"> 

<Description/> 

<Grade>03</Grade> 

<Required>1</Required> 

<Authorized>2</Authorized> 

</Personnel> 

<Personnel  code="11B30"> 

<Description/> 

<Grade>E6</Grade> 

<Required>2</Required> 

<Authorized>6</Authorized> 

</Personnel> 

<Equipment  code="Linebacker"> 

<Description>Air-defence</Description> 

<Required>6</Required> 

<Authorized>9</Authorized> 

</Equipment> 

<Equipment  code="M8  Alarm"> 

<Description>Automated  biological  detector</Description> 
<Required>2</Required> 

<Authorized>2</Authorized> 
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</Equipment> 

</Resource> 

</Unit> 

<Unit  UIC=""  dataSource=""> 

<Name>3rd  Armored  Cavalry  Regiment</Name> 
<Present> 

<Name>Current  Loc</Name> 

<Latitude>latit2</Latitude> 

<Longitude>long2</Longitude> 

</Present> 

<DescriptionCode>AAC</DescriptionCode> 
<LevelCode>RGT  </LevelCode> 

<Resource> 

<Personnel  code="92Y40"> 

<Description/> 

<Grade>E7</Grade> 

<Required>3</Required> 

<Authorized>5</Authorized> 

</Personnel> 

<Personnel  code="92Y10"> 

<Description/> 

<Grade>E3</Grade> 

<Required>1</Required> 

<Authorized>3</Authorized> 

</Personnel> 

<Equipment  code="M1098  HMMWV"> 
<Description>Ambulance</Description> 
<Required>10</Required> 
<Authorized>15</Authorized> 
</Equipment> 

<Equipment  code="Avenger2"> 

<Description>Air-defence</Description> 

<Required>3</Required> 

<Authorized>2</Authorized> 

</Equipment> 

</Resource> 

</Unit> 

</Units> 

</UOB> 
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APPENDIX  E.  AUTHOR-GENERATED  XML  SCHEMA  FOR  UOB 


This  document  was  created  by  the  author  using  the  XMLSPY  IDE  for  XML 
authoring.  The  content  for  the  schema  is  derived  from  the  information  in  the 
UOB  DAT  and  is  not  the  UOB  governing  schema.  The  UOB  governing  schema 
is  found  in  Appendix  B.  This  schema  was  developed  during  the  early  stages  of 
this  research  when  the  author  was  unable  to  extract  the  files  necessary  from  the 
UOB  version  7.4  Toolset.  Version  7.7  corrected  the  extraction  problems.  This 
schema  and  the  UOB  DAT  schema  differ  in  the  manner  in  which  they  restrict 
what  data  is  allowed  in  many  locations  of  the  result  document.  The  UOB  version 
7.7  schema  is  not  as  restrictive  or  directive  as  this  schema. 


<?xml  version="1.0"  encoding="UTF-8"?> 

<xs:schema  xmlns:xs="http://www. w3.org/2001/XMLSchema"  elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 

<xs:element  name="UnitData"> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name="AdministrativeUnitlnformation"> 

<xs:annotation> 

<xs:documentation> 

This  is  the  information  including  the  units  size  by  the  echelon  it  occupies,  the 
type  of  unit  and  its  name  or  how  it  is  refered  to  in  formal  military  communications. 
</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name="ParentUIC"  type="xs:string"/> 

<xs:element  name="ParentUTC"  type="xs:string"/> 

<xs:element  name="ParentULC"  type="xs:string"/> 

<xs:element  name="SRC"  type="xs:string"/> 

<xs:element  name-'UnitUIC"  type="xs:string"/> 

<xs:element  name-'UnitName"  type="xs:string"/> 

<xs:element  name-'UnitTypeCode"  type="xs:string"/> 

<xs:element  name="UnitLevelCode"> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:enumeration  value="SEC"/> 

<xs:enumeration  value="SQD"/> 

<xs:enumeration  value="PLT"/> 

<xs:enumeration  value="HFT"/> 

<xs:enumeration  value="TRP"/> 

<xs:enumeration  value="CO"/> 

<xs:enumeration  value="SQ"/> 

<xs:enumeration  value="BN7> 
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<xs:enumeration  value="REG"/> 

<xs:enumeration  value="BDE"/> 

<xs:enumeration  value="DIV7> 

<xs:enumeration  value="CPS7> 

<xs:enumeration  value="A7> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="UnitDescriptionCode"> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:enumeration  value="AAC7> 

<xs:enumeration  value="AAS"/> 

<xs:enumeration  value="AAV"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="PresentLongitude"  type="xs:string"/> 

<xs:element  name="PresentLatitude"  type="xs:string"/> 

<xs:element  name="PresentLocationName"  type="xs:string"/> 
<xs:element  name="HomeLongitude"  type="xs:string"/> 

<xs:element  name="HomeLatitude"  type="xs:string"/> 

<xs:element  name="HomeLocationName"  type="xs:string7> 

<xs:element  name="CountryCode"  type="xs:string"/> 

<xs:element  name="ShipCategory"  type="xs:string"  minOccurs="07> 
<xs:element  name="ShipCategoryName"  type="xs:string" 

minOccurs="0"/> 

<xs:element  name="ShipClass"  type- 'xs:string"  minOccurs="07> 
<xs:element  name="ShipHullNumber"  type="xs:integer"  minOccurs="07> 
<xs:element  name="Source"  type="xs:string"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element  name="Personnel"  minOccurs="1"  maxOccurs="unbounded"> 
<xs:annotation> 

<xs:documentation> 

This  is  the  information  encoded  from  (JOB.  It  is  broken  down  as  it  is 
displayed  in  UOB  and  is  currently  configured  for  US  Army  units  only.  Additional  rules  need  to  be 
added  to  encompass  all  US  and  NATO  units. </xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element  name="JobDescription"  type="xs:string"/> 

<xs:element  name="MilitaryOccupationSpecialityCode"> 
<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:pattern  value="[0-9]{2}[A-Z]{1  }([0-9]{2}|[0-9]{1  }[A-Z]{1  })"/> 
</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="MilitaryRank"> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:enumeration  value="PVT7> 

<xs:enumeration  value="PV2"/> 

<xs:enumeration  value="PFC"/> 
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<xs:enumeration  value="SPC"/> 

<xs:enumeration  value="SGT"/> 

<xs:enumeration  value="SSG"/> 

<xs:enumeration  value="SFC"/> 

<xs:enumeration  value="MSG"/> 

<xs:enumeration  value="1SG"/> 

<xs:enumeration  value="SGM"/> 

<xs:enumeration  value="CSM"/> 

<xs:enumeration  value="2LT"/> 

<xs:enumeration  value="1LT"/> 

<xs:enumeration  value="CPT"/> 

<xs:enumeration  value="MAJ"/> 

<xs:enumeration  value="LTC"/> 

<xs:enumeration  value="COL"/> 

<xs:enumeration  value="BG"/> 

<xs:enumeration  value="MG"/> 

<xs:enumeration  value="LTG"/> 

<xs:enumeration  value="GEN"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="MilitaryGrade"> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:enumeration  value="E1"/> 

<xs:enumeration  value="E2"/> 

<xs:enumeration  value="E3"/> 

<xs:enumeration  value="E4"/> 

<xs:enumeration  value="E5"/> 

<xs:enumeration  value="E6"/> 

<xs:enumeration  value="E7"/> 

<xs:enumeration  value="E8"/> 

<xs:enumeration  value="E9"/> 

<xs:enumeration  value="01"/> 

<xs:enumeration  value="02"/> 

<xs:enumeration  value="03"/> 

<xs:enumeration  value="04"/> 

<xs:enumeration  value="05"/> 

<xs:enumeration  value="06"/> 

<xs:enumeration  value="07"/> 

<xs:enumeration  value="08"/> 

<xs:enumeration  value="09"/> 

<xs:enumeration  value="O10"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name-'NumberRequired"  type="xs:nonNegativelnteger"/> 
<xs:element  name-'NumberAuthorized"  type="xs:nonNegativelnteger"/> 
<xs:element  name-'NumberOnHand"  type="xs:nonNegativelnteger"/> 
</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element  name="UnitEquipment"  minOccurs="1"  maxOccurs="unbounded"> 
<xs:complexType> 

<xs:sequence> 

<xs:element  name="EquipmentDescription"  type="xs:string"/> 
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<xs:element  name="EquipmentCode"> 

<xs:simpleType> 

<xs:restriction  base="xs:string"> 

<xs:pattern  value="[A-Z]{1  }[0-9]{5}"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element  name="NumberRequired"  type="xs:nonNegativelnteger"/> 
<xs:element  name-'NumberAuthorized"  type="xs:nonNegativelnteger"/> 
<xs:element  name-'EquipmentPiecesOnHand" 
type="xs:nonNegativelnteger"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:schema> 
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APPENDIX  F.  AUTHOR-GENERATED  EXAMPLE  UNIT 

DOCUMENT 


The  following  is  a  manually  generated  XML  document  describing  A  Troop 
1st  Squadron  3rd  Armored  Cavalry  Regiment  using  Altova’s  XMLSPY  Enterprise 
Edition  2004.  All  of  the  data  in  this  document  was  taken  from  the  UOB  Client 
Version  7.4  data  base.  Element  tags  are  based  on  the  descriptions  used  in  the 
UOB  toolset.  This  document  validates  with  the  XML  Schema  in  Appendix  E  but 
is  not  an  extracted  file  from  the  UOB  database.  The  file  extracted  and  used  to 
conduct  the  transformations  described  in  Chapter  V  is  located  in  Appendix  B. 

<?xml  version="1.0"  encoding- 'UTF-8"?> 

<?xml-stylesheet  type="text/xsl"  href="C:\Graduate  Courses\Fall  04  Quarter\MV  3250 
XML\GenericTransform.xsl"?> 

<UnitData  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="UnitData.xsd"> 

<AdministrativeUnitlnformation> 

<ParentUIC>WG2LAA</ParentUIC> 

<ParentUTC>2YUTT</ParentUTC> 

<ParentULC>SQ</ParentULC> 

<SRC>17487L000</SRC> 

<UnitUIC>WG2LA0</UnitUIC> 

<UnitName>Squadron  3rd  Armored  Cavalry,  A  CAV  TRP,  CAV  SQDN</UnitName> 
<UnitTypeCode>2</UnitTypeCode> 

<UnitLevelCode>TRP</UnitLevelCode> 

<UnitDescriptionCode>AAC</UnitDescriptionCode> 

<PresentLongitude/> 

<PresentLatitude/> 

<PresentLocationName>lraq</PresentLocationName> 

<HomeLongitude/> 

<HomeLatitude/> 

<HomeLocationName>Colorado</HomeLocationName> 

<CountryCode>US</CountryCode> 

<Source>UOB</Source> 

</AdministrativeUnitlnformation> 

<Personnel> 

<JobDescription>Assistant  Gunner</JobDescription> 

<MilitaryOccupationSpecialityCode>1 1C10</MilitaryOccupationSpecialityCode> 
<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Gunner</JobDescription> 

<MilitaryOccupationSpecialityCode>1 1C10</MilitaryOccupationSpecialityCode> 
<MilitaryRank>PFC</MilitaryRank> 
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<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Carrier  Driver</JobDescription> 

<MilitaryOccupationSpecialityCode>1 1  Cl  0</MilitaryOccupationSpecialityCode> 
<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Squad  Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>1 1C30</MilitaryOccupationSpecialityCode> 
<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Section  Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>1 1C40</MilitaryOccupationSpecialityCode> 
<MilitaryRank>SFC</MilitaryRank> 

<MilitaryGrade>E7</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Platoon  Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>12BOO</MilitaryOccupationSpecialityCode> 

<MilitaryRank>2LT</MilitaryRank> 

<MilitaryGrade>01</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Commander</JobDescription> 

<MilitaryOccupationSpecialityCode>12COO</MilitaryOccupationSpecialityCode> 

<MilitaryRank>CPT</MilitaryRank> 

<MilitaryGrade>03</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Executive  Officer</JobDescription> 

<MilitaryOccupationSpecialityCode>12BOO</MilitaryOccupationSpecialityCode> 

<MilitaryRank>1LT</MilitaryRank> 

<MilitaryGrade>02</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 
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<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Platoon  Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>12COO</MilitaryOccupationSpecialityCode> 

<MilitaryRank>2LT</MilitaryRank> 

<MilitaryGrade>01</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Carrier  Driver</JobDescription> 

<MilitaryOccupationSpecialityCode>19D10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Scout</JobDescription> 

<MilitaryOccupationSpecialityCode>19D10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Scout</JobDescription> 

<MilitaryOccupationSpecialityCode>19D10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>CFV  Driver</JobDescription> 

<MilitaryOccupationSpecialityCode>19D10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Vehicle  Driver</JobDescription> 

<MilitaryOccupationSpecialityCode>19D10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 
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</Personnel> 

<Personnel> 

<JobDescription>CFV  Gunner</JobDescription> 

<MilitaryOccupationSpecialityCode>19D20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Squad  Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>19D30</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Section  Leader</JobDescription> 

<MilitaryOccupationSpecialityCode>19D30</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Platoon  Sergeant</JobDescription> 

<MilitaryOccupationSpecialityCode>19D40</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SFC</MilitaryRank> 

<MilitaryGrade>E7</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Tank  Crew  Loader</JobDescription> 

<MilitaryOccupationSpecialityCode>19K10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Tank  Crewman</JobDescription> 

<MilitaryOccupationSpecialityCode>19K10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 
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<JobDescription>Gunner/Assistant  TC</JobDescription> 

<MilitaryOccupationSpecialityCode>19D20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Tank  Commander</JobDescription> 

<MilitaryOccupationSpecialityCode>19K30</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Tank  Commander/Master  Gunner</JobDescription> 

<MilitaryOccupationSpecialityCode>19K30</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Platoon  Sergeant</JobDescription> 

<MilitaryOccupationSpecialityCode>19K40</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SFC</MilitaryRank> 

<MilitaryGrade>E7</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>First  Sergeant</JobDescription> 

<MilitaryOccupationSpecialityCode>19Z5M</MilitaryOccupationSpecialityCode> 

<MilitaryRank>1SG</MilitaryRank> 

<MilitaryGrade>E8</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>M1  Tank  Turret  Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>45E10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>M1  Tank  Turret  Mechanic</JobDescription> 
<MilitaryOccupationSpecialityCode>45E10</MilitaryOccupationSpecialityCode> 
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<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>BFV  Turret  Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>45T10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>BFV  Turret  Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>45T20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>NBC  NCO</JobDescription> 

<MilitaryOccupationSpecialityCode>54B20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>M1  Tank  Auto  Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>63E10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Recovery  Vehicle  Operator</JobDescription> 

<MilitaryOccupationSpecialityCode>63E20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>M1  Tank  Maintenance  Supervisor</JobDescription> 

<MilitaryOccupationSpecialityCode>63E40</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SFC</MilitaryRank> 

<MilitaryGrade>E7</MilitaryGrade> 
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<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Recovery  Vehicle  Operator</JobDescription> 

<MilitaryOccupationSpecialityCode>63T10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>BFV  System  Auto  Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>63T10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>BFV  System  Auto  Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>63T10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>PFC</MilitaryRank> 

<MilitaryGrade>E3</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>BFV  System  Auto  Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>63T20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>BFV  System  Mechanic</JobDescription> 

<MilitaryOccupationSpecialityCode>63T30</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Equipment  Rec/Parts  Specialist  (PLL  Clerk)</JobDescription> 
<MilitaryOccupationSpecialityCode>92A10</MilitaryOccupationSpecialityCode> 
<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 
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<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Equip  Rec/Parts  Sergeant</JobDescription> 

<MilitaryOccupationSpecialityCode>92A20</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SGT</MilitaryRank> 

<MilitaryGrade>E5</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Armorer</JobDescription> 

<MilitaryOccupationSpecialityCode>92Y10</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SPC</MilitaryRank> 

<MilitaryGrade>E4</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<Personnel> 

<JobDescription>Supply  Sergeant</JobDescription> 

<MilitaryOccupationSpecialityCode>92Y30</MilitaryOccupationSpecialityCode> 

<MilitaryRank>SSG</MilitaryRank> 

<MilitaryGrade>E6</MilitaryGrade> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<NumberOnHand>0</NumberOnHand> 

</Personnel> 

<UnitEquipment> 

<EquipmentDescription>ADAPTER  HARDWARE:  FVS  PECULIAR  (STE- 
M1/FVS)</EquipmentDescription> 

<EquipmentCode>A10769</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ADAPTER  HARDWARE:  Ml  PECULIAR  (STE- 
M1/FVS)</EquipmentDescription> 

<EquipmentCode>A10837</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>AIMING  CIRCLE</EquipmentDescription> 

<EquipmentCode>A22496</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ALARM,  CHEMICAL  AGENT  AUTOMATIC 
M22</EquipmentDescription> 

<EquipmentCode>A33020</EquipmentCode> 
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<NumberRequired>1 1</NumberRequired> 

<NumberAuthorized>11</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ANALYZER  SET  ENGINE:  PORTABLE  SOLID  STATE 
(STE/ICEPM)</EquipmentDescription> 

<EquipmentCode>A56243</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ADAPTER  TEST  ELECTRICAL  SYSTEM  BREAKOUT:  Ml 
TANK</EquipmentDescription> 

<EquipmentCode>A70522</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ANTENNA  GROUP:  OE-254()/GRC</EquipmentDescription> 

<EquipmentCode>A79381</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>AXLE  CABLE  REEL:  RL-27</EquipmentDescription> 

<EquipmentCode>B07126</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>1</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>BAYONET-KNIFE:  W/SCABBARD  FOR  M16A1 
RIFLE</EquipmentDescription> 

<EquipmentCode>B49272</EquipmentCode> 

<NumberRequired>132</NumberRequired> 

<NumberAuthorized>132</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>BINOCULAR:  MODULAR  CONSTRUCTION  MIL  SCALE 
RETICLE  7X50MM  W/E</EquipmentDescription> 

<EquipmentCode>B67766</EquipmentCode> 

<NumberRequired>26</NumberRequired> 

<NumberAuthorized>26</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>BORESIGHTING  EQUIPMENT  WEAPON:  MUZZLE 
ALIGNMENT</EquipmentDescription> 

<EquipmentCode>B90494</EquipmentCode> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 
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<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CONTROL  RECEIVER-TRANSMITTER:  C- 
1 1 561  (C)/U</EquipmentDescription> 

<EquipmentCode>C05541</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MONITOR  CHEMICAL  AGENT</EquipmentDescription> 

<EquipmentCode>C05701</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CARRIER  120  MILLIMETER  MORTAR:  SELF  PROPELLED 
ARMORED</EquipmentDescription> 

<EquipmentCode>C10990</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CARRIER  PERSONNEL  FULL  TRACKED:  ARMORED 
(RISE)</EquipmentDescription> 

<EquipmentCode>C18234</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>COMPUTER  SET:  DIGITAL  OL- 
582/TYQ</EquipmentDescription> 

<EquipmentCode>C18446</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>COMPUTER  SET:  DIGITAL  OL- 
582/TYQ</EquipmentDescription> 

<EquipmentCode>C18514</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CABLE  TELEPHONE:  WD-1/TT  DR-8  1/2 
KM</EquipmentDescription> 

<EquipmentCode>C687 1 9</EquipmentCode> 
<NumberRequired>46</NumberRequired> 
<NumberAuthorized>46</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 
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</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CABLE  TELEPHONE:  WD-1/TT  RL-159/U  2 
KM</EquipmentDescription> 

<EquipmentCode>C68856</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CAMOUFLAGE  SCREEN  SUPPORT  SYSTEM: 
WOODLAND/DESERT </EquipmentDescription> 

<EquipmentCode>C89070</EquipmentCode> 

<NumberRequired>92</NumberRequired> 

<NumberAuthorized>92</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CAMOUFLAGE  SCREEN  SYSTEM:  WOODLAND  LT  WT 
RADAR  SCAT  W/O  SPT  SYS</EquipmentDescription> 
<EquipmentCode>C89145</EquipmentCode> 
<NumberRequired>92</NumberRequired> 
<NumberAuthorized>92</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CONTROL  REMOTE  LANDMINE  SYSTEM: 

M7 1  </EquipmentDescription> 

<EquipmentCode>C96840</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>DIGITAL  DATA  SET:  AN/PSG-7V1</EquipmentDescription> 
<EquipmentCode>D10788</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CARRIER  COMMAND  POST:  LIGHT 
TRACKED</EquipmentDescription> 

<EquipmentCode>D1 1 538</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>DIGITAL  NON-SECURE  VOICE  TERMINAL  W/DIGITAL  DATA 
PORT :  TA-1 042A</EquipmentDescription> 

<EquipmentCode>D60801</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 
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<UnitEquipment> 

<EquipmentDescription>DATA  TRANSFER  DEVICE:  AN/CYZ-10</EquipmentDescription> 
<EquipmentCode>D78555</EquipmentCode> 

<NumberRequired>44</NumberRequired> 

<NumberAuthorized>44</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>CHARGER  BATTERY:  PP-34/MSM</EquipmentDescription> 
<EquipmentCode>D99573</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ELECTRONIC  TEST  SET:  TS-4348/UV</EquipmentDescription> 
<EquipmentCode>E03826</EquipmentCode> 

<NumberRequired>5</NumberRequired> 

<NumberAuthorized>5</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>COMPASS  MAGNETIC  UNMOUNTED:  MIL 
GRADUATIONS</EquipmentDescription> 

<EquipmentCode>E63728</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>COMP  UNIT  RCP:  TRK  2  WHL  PNEU  TIRES  GAS  DRVN  5  CFM 
175  PSI</EquipmentDescription> 

<EquipmentCode>E70064</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>ELEC  TRANSFER  KEYING  DEVICE  ETKD:  KYK- 
13/TSEC</EquipmentDescription> 

<EquipmentCode>E98103</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>FIGHTING  VEHICLE:  FULL  TRACKED  CAVALRY  HI 
SURVIVABILITY  (CFV)</EquipmentDescription> 

<EquipmentCode>F60530</EquipmentCode> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>DEMOLITION  SET  EXPLOSIVE:  INITIATING  NON 
ELECTRIC</EquipmentDescription> 
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<EquipmentCode>F91627</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>DETECTING  SET  MINE:  PTBL  METALLIC  (AN/PSS- 
1 1  )</EquipmentDescription> 

<EquipmentCode>G02341</EquipmentCode> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>GEN  SET:  DED  SKID  MTD  3KW  60HZ</EquipmentDescription> 
<EquipmentCode>G18358</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>HEATER  DUCT  TYPE  PTBL:  GAS  250000BTU  WHL 
MTD</EquipmentDescription> 

<EquipmentCode>K24862</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>KIT  GROUND  HOP:  Ml  TANK</EquipmentDescription> 
<EquipmentCode>K27594</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>KIT  GROUND  HOP:  IFV/CFV</EquipmentDescription> 
<EquipmentCode>K41392</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>KY-99:  MINTERM</EquipmentDescription> 
<EquipmentCode>K47623</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>HOSE  COT  RUB  LINE:  M-F  CPLG  1-1/2  IN  1-1/2  NPSH  25  FT 
LONG</EquipmentDescription> 

<EquipmentCode>K53748</EquipmentCode> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 
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</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LASER  INFRARED  OBSERVATION  SET:  AN/GVS- 
5</EquipmentDescription> 

<EquipmentCode>L40063</EquipmentCode> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LAUNCHER  GRENADE  ARMAMENT  SUBSYSTEM: 
M257</EquipmentDescription> 

<EquipmentCode>L44031</EquipmentCode> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LAUNCHER  GRENADE  40  MILLIMETER:  SGLE  SHOT  RIFLE 
MTD  DTCHBLE  W/E</EquipmentDescription> 

<EquipmentCode>L44595</EquipmentCode> 

<NumberRequired>16</NumberRequired> 

<NumberAuthorized>16</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LAUNCHER  GRENADE  ARMAMENT  SUBSYSTEM: 
SCREENING  RED  PHOSPHO  M239</EquipmentDescription> 
<EquipmentCode>L44612</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LAUNCHER  GRENADE  SMOKE:  SCREENING  RP 
M250</EquipmentDescription> 

<EquipmentCode>L44680</EquipmentCode> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LAUNCHER  GRENADE  ARMAMENT  SUBSYSTEM:  SCREEN 
RP  M259</EquipmentDescription> 

<EquipmentCode>L44748</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>LIGHTWEIGHT  DIGITAL  FACSIMILE:  AN/UXC- 
7</EquipmentDescription> 

<EquipmentCode>L67964</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 
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</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MACHINE  GUN  CALIBER  .50:  HB  FLEXIBLE  (GROUND  AND 
VEHICLE)  W/E</EquipmentDescription> 

<EquipmentCode>L91975</EquipmentCode> 

<NumberRequired>16</NumberRequired> 

<NumberAuthorized>16</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MACHINE  GUN  7.62  MILLIMETER: 
FIXED</EquipmentDescription> 

<EquipmentCode>L92352</EquipmentCode> 

<NumberRequired>18</NumberRequired> 

<NumberAuthorized>18</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MASK  CHEMICAL  BIOLOGICAL:  M40</EquipmentDescription> 
<EquipmentCode>M12418</EquipmentCode> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MASK  CHEMICAL  BIOLOGICAL:  COMBAT  VEHICLE 
M42</EquipmentDescription> 

<EquipmentCode>M18526</EquipmentCode> 

<NumberRequired>1 19</NumberRequired> 

<NumberAuthorized>1 19</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MISSILE  SIMULATION  ROUND:  (TOW)</EquipmentDescription> 
<EquipmentCode>M51419</EquipmentCode> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MULTIMETER  DIGITAL:  AN/PSM-45</EquipmentDescription> 
<EquipmentCode>M60449</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MORTAR:  SUBCALIBER  INSERT  120  MILLIMETER 
M303</EquipmentDescription> 

<EquipmentCode>M68258</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MORTAR  120  MILLIMETERS</EquipmentDescription> 
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<EquipmentCode>M68405</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MOUNT  GUN:  RING  CAL  .50</EquipmentDescription> 

<EquipmentCode>M74364</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MINI  EYESAFE  LASER  INFRARED  OBSERVATION  SET 
(MELIOS):  AN/PVS-6</EquipmentDescription> 

<EquipmentCode>M74849</EquipmentCode> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MOUNT  TRIPOD  MACHINE  GUN:  HEAVY  CALIBER 
50</EquipmentDescription> 

<EquipmentCode>M75577</EquipmentCode> 

<NumberRequired>6</NumberRequired> 

<NumberAuthorized>6</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MACHINE  GUN  7.62  MILLIMETER:  FIXED  RH 
FEED</EquipmentDescription> 

<EquipmentCode>M92420</EquipmentCode> 

<NumberRequired>13</NumberRequired> 

<NumberAuthorized>13</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MACHINE  GUN:  7.62MM  M240B</EquipmentDescription> 

<EquipmentCode>M92841</EquipmentCode> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>NIGHT  VISION  SIGHT  CREW  SERVED  WEAPON:  AN/TVS- 
5</EquipmentDescription> 

<EquipmentCode>N04596</EquipmentCode> 

<NumberRequired>6</NumberRequired> 

<NumberAuthorized>6</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>NIGHT  VISION  SIGHT  INDIVIDUAL  SERVED  WEAPON: 
AN/PVS-4</EquipmentDescription> 

<EquipmentCode>N04732</EquipmentCode> 

<NumberRequired>12</NumberRequired> 
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<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>NIGHT  VISION  SIGHT  SET:  AN/UAS- 
1 1</EquipmentDescription> 

<EquipmentCode>N05050</EquipmentCode> 

<NumberRequired>6</NumberRequired> 

<NumberAuthorized>6</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>NIGHT  VISION  GOGGLE:  AN/PVS-7B</EquipmentDescription> 
<EquipmentCode>N05482</EquipmentCode> 

<NumberRequired>90</NumberRequired> 

<NumberAuthorized>90</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>NAVIGATION  SET  SATELLITE  SYSTEMS:  AN/PSN- 
1 1</EquipmentDescription> 

<EquipmentCode>N95862</EquipmentCode> 

<NumberRequired>30</NumberRequired> 

<NumberAuthorized>30</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>PLATOON  EARLY  WARNING  SYSTEM:  AN/TRS- 
2(V)</EquipmentDescription> 

<EquipmentCode>P06148</EquipmentCode> 

<NumberRequired>6</NumberRequired> 

<NumberAuthorized>6</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>PLOTTING  BOARD  INDIRECT  FIRE: 
AZIMUTH</EquipmentDescription> 

<EquipmentCode>P07900</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>PJH  SURFACE  VEHICLE  RADIO  SET:  AN/VSQ-2(V)1 
(PJHI)</EquipmentDescription> 

<EquipmentCode>P49587</EquipmentCode> 

<NumberRequired>8</NumberRequired> 

<NumberAuthorized>8</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>PURGING  KIT  FIRE  CONTROL:  ORG 
MAINT</EquipmentDescription> 

<EquipmentCode>P70517</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 
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<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>PISTOL  9MM  AUTOMATIC:  M9</EquipmentDescription> 

<EquipmentCode>P98152</EquipmentCode> 

<NumberRequired>78</NumberRequired> 

<NumberAuthorized>78</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>QUADRANT  FIRE  CONTROL: 

GUNNERS</EquipmentDescription> 

<EquipmentCode>Q03468</EquipmentCode> 

<NumberRequired>11</NumberRequired> 

<NumberAuthorized>11</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIAC  SET :  AN/VDR-2</EquipmentDescription> 

<EquipmentCode>R20684</EquipmentCode> 

<NumberRequired>11</NumberRequired> 

<NumberAuthorized>11</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO  SET:  AN/GRC-213</EquipmentDescription> 

<EquipmentCode>R30895</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIAC  SET :  AN/PDR-75</EquipmentDescription> 

<EquipmentCode>R30925</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIAC  SET:  AN/UDR-13</EquipmentDescription> 

<EquipmentCode>R31061</EquipmentCode> 

<NumberRequired>28</NumberRequired> 

<NumberAuthorized>28</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO  SET :  ANA/RC-89D</EquipmentDescription> 

<EquipmentCode>R44931</EquipmentCode> 

<NumberRequired>7</NumberRequired> 

<NumberAuthorized>7</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO  SET :  ANA/RC-92D</EquipmentDescription> 

<EquipmentCode>R45475</EquipmentCode> 

<NumberRequired>4</NumberRequired> 

160 


<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RECOVERY  VEHICLE  FULL  TRACKED: 
MEDIUM</EquipmentDescription> 

<EquipmentCode>R50681</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>REEL  EQUIPMENT :  CE-1 1  </EquipmentDescription> 

<EquipmentCode>R56742</EquipmentCode> 

<NumberRequired>18</NumberRequired> 

<NumberAuthorized>18</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>REELING  MACHINE  CABLE  HAND:  RL- 
31  </EquipmentDescription> 

<EquipmentCode>R59023</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>REELING  MACHINE  CABLE  HAND:  RL- 
39</EquipmentDescription> 

<EquipmentCode>R59160</EquipmentCode> 

<NumberRequired>27</NumberRequired> 

<NumberAuthorized>27</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO  SET :  ANA/RC-87D</EquipmentDescription> 

<EquipmentCode>R67228</EquipmentCode> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO  SET :  ANA/RC-90D</EquipmentDescription> 

<EquipmentCode>R67976</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RADIO  SET :  ANA/RC-91  D</EquipmentDescription> 

<EquipmentCode>R68078</EquipmentCode> 

<NumberRequired>14</NumberRequired> 

<NumberAuthorized>14</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 
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<EquipmentDescription>RIFLE  5.56  MILLIMETER:  M16A2</EquipmentDescription> 

<EquipmentCode>R95035</EquipmentCode> 

<NumberRequired>50</NumberRequired> 

<NumberAuthorized>50</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>RIFLE  5  56  MILLIMETER:  M4</EquipmentDescription> 

<EquipmentCode>R97234</EquipmentCode> 

<NumberRequired>24</NumberRequired> 

<NumberAuthorized>24</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SAW  CHAIN:  GAS  DRVN  BAR  FRAME 
W/ACCESS/COMPONENTS</EquipmentDescription> 
<EquipmentCode>S35741</EquipmentCode> 
<NumberRequired>4</NumberRequired> 
<NumberAuthorized>4</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SPEECH  SCTY  EQUIP  DIGITAL  SUBSCRIBER  VOICE 
TERMINAL:  TSEC/KY-68</EquipmentDescription> 
<EquipmentCode>S64488</EquipmentCode> 
<NumberRequired>1</NumberRequired> 
<NumberAuthorized>1</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TEST  SET:  COMMON  CORE  (STE- 
M1/FVS)</EquipmentDescription> 

<EquipmentCode>T06859</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TANK  COMBAT  FULL  TRACKED:  120MM  GUN 
M1A2</EquipmentDescription> 

<EquipmentCode>T  1 3305</EquipmentCode> 
<NumberRequired>9</NumberRequired> 
<NumberAuthorized>9</NumberAuthorized> 
<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquiprnentDescription>TONE-SIGNALLING  ADAPTER:  TA-977( 
)/PT</EquipmentDescription> 

<EquipmentCode>T25726</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TELEPHONE  WIRE  WITH  REEL:  MX- 
10891/G</EquipmentDescription> 
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<EquipmentCode>T31872</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SIGHT  BORE  OPTICAL:</EquipmentDescription> 
<EquipmentCode>T45593</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TENT :  LIGHTWEIGHT  MAINTENANCE  ENCLOSURE 
(LME)</EquipmentDescription> 

<EquipmentCode>T49947</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TERMINAL  RADIO-TELEPHONE  MOBILE  SUBSCRIBER: 
AN/VRC-97</EquipmentDescription> 

<EquipmentCode>T55957</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL  KIT  MECHANICS</EquipmentDescription> 
<EquipmentCode>T58051</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TRUCK  CARGO:  4X4  LMTV  W/E</EquipmentDescription> 
<EquipmentCode>T60081</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TRUCK  CARGO:  4X4  LMTV  W/E  W/W</EquipmentDescription> 
<EquipmentCode>T60149</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TRUCK  UTILITY:  CARGO/TROOP  CARRIER  1-1/4  TON  4X4 
W/E  (HMMWV)</EquipmentDescription> 

<EquipmentCode>T61494</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 
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</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL  SET  BATTALION  MAINTENANCE  TEAM:  ARMOR/MECH 
INF/FLD  ARTY</EquipmentDescription> 

<EquipmentCode>T62405</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SPLICING  KIT  TELEPHONE  CABLE:  MK- 
356/G</EquipmentDescription> 

<EquipmentCode>U05008</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SWITCHBOARD  TELEPHONE  MANUAL:  SB- 
22/PT  </EquipmentDescription> 

<EquipmentCode>U81707</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TELEPHONE  SET:  TA-312/PT</EquipmentDescription> 
<EquipmentCode>V3121 1</EquipmentCode> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TELESCOPE  STRAIGHT:  MILITARY</EquipmentDescription> 
<EquipmentCode>V35477</EquipmentCode> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>POWER  SUPPLY  VEHICLE:  HYP- 
57/TSEC</EquipmentDescription> 

<EquipmentCode>V98788</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TESTER  AIR  FLOW:  USED  ON  VEHICLES  W/GAS 
PARTICULATE  FILTER  UNITS  </EquipmentDescription> 
<EquipmentCode>W02526</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 
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<EquipmentDescription>TOOL  KIT  ARTILLERY  MECHANICS: 
ORD</EquipmentDescription> 

<EquipmentCode>W32182</EquipmentCode> 

<NumberRequired>4</NumberRequired> 

<NumberAuthorized>4</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>SHOP  EQUIPMENT  AUTO  MAINT  AND  REPAIR:  OM  COMMON 
NO  1  LESS  POWER</EquipmentDescription> 

<EquipmentCode>W32593</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL  KIT  GENERAL  MECHANICS: 
AUTOMOTIVE</EquipmentDescription> 

<EquipmentCode>W33004</EquipmentCode> 

<NumberRequired>9</NumberRequired> 

<NumberAuthorized>9</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL  KIT  CARPENTERS:  ENGINEER  SQUAD  W/CHEST 
</EquipmentDescription> 

<EquipmentCode>W34648</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL  KIT  PIONEER  ENGINEER  COMBAT  PLATOON:  TOOLS 
FOR  MANUAL  LABOR</EquipmentDescription> 

<EquipmentCode>W48074</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TOOL  KIT  SMALL  ARMS  REPAIRMAN: 
ORDNANCE</EquipmentDescription> 

<EquipmentCode>W51 91 0</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TRAILER  TANK:  WATER  400  GALLON  1-1/2  TON  2  WHEEL 
W/E</EquipmentDescription> 

<EquipmentCode>W98825</EquipmentCode> 

<NumberRequired>1</NumberRequired> 

<NumberAuthorized>1</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 
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<EquipmentDescription>VIEWER  INFRARED:  AN/PAS-7</EquipmentDescription> 
<EquipmentCode>Y03104</EquipmentCode> 

<NumberRequired>12</NumberRequired> 

<NumberAuthorized>12</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>WRENCH  TORQUE:  3/4  IN  SQ  MALE  DRIVE  600  FT-LB 
CAPACITY</EquipmentDescription> 

<EquipmentCode>Y85377</EquipmentCode> 

<NumberRequired>3</NumberRequired> 

<NumberAuthorized>3</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>TRAILER  CARGO:  LMTV 
W/DROPSIDES</EquipmentDescription> 

<EquipmentCode>Z36068</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MORTAR  BALLISTIC  COMPUTER: 
XM30</EquipmentDescription> 

<EquipmentCode>Z44784</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

<UnitEquipment> 

<EquipmentDescription>MAST  ANTENNA  10  METERS:  AB-XXX</EquipmentDescription> 
<EquipmentCode>Z63141</EquipmentCode> 

<NumberRequired>2</NumberRequired> 

<NumberAuthorized>2</NumberAuthorized> 

<EquipmentPiecesOnHand>0</EquipmentPiecesOnHand> 

</UnitEquipment> 

</UnitData> 
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